AFIT/GCS/ENG/93D-03 


AD-A274  091 

■llllllll  ^ 


DTIC 


ELFCTE 
DEC  2  3 1993 


Using  Database  Technology  to  Support 
Domain-Oriented  Application  Composition  Systems 


THESIS 

Danny  Alan  Cecil  Joseph  AIeui  FuUenkamp 

Captain,  USAF  Captain,  USAF 

AFIT/GCS/ENG/93D-03 


Approved  for  public  release;  distribution  unlimited 

l2  22  09’<'_ 


AFIT/GCS/ENG/93D-03 


Using  Database  Technology  to  Support  Domain-Oriented  Application  Composition 

Systems 


THESIS 


Presented  to  the  Faculty  of  the  Graduate  School  of  Engineering 
of  the  Air  Force  Institute  of  Technology 
Air  University 
In  P2ui:id  Fulfillment  of  the 
Requirements  for  the  Degree  of 
Master  of  Science 


DTIC 

ri,ECTE| 
DEC231393| 

E 


Danny  Alan  Cecil,  B.S. 
Captain,  USAF 


Joseph  Alan  FuUenkamp,  B.S. 
Captain,  USAF 


December,  1993 


Approved  for  public  release;  distribution  unlimited 


Acknowledgments 


I  would  like  to  thank  Major  Paul  Bailor,  Maj  Metrk  Roth,  and  Maj  David  Luginbuhl 
for  their  timely  advice  and  thought-provoking  questions  diuring  this  thesis  effort.  Their 
guidance,  confidence  and  encouragement  were  invaluable.  I  would  also  like  to  thank  Mr. 
Dan  Zambon  and  Mr.  David  Doak  for  providing  a  superb  laboratory  environment  in  which 
to  conduct  research.  Those  that  provide  outstanding  service  are  quite  often  overlooked.  I 
would  like  to  thank  the  rest  of  the  knowledge-based  software  engineering  research  group, 
especially  my  research  partner  Captain  Joe  PuUenkamp,  for  keeping  me  from  going  too  far 
astray  during  this  research. 

Most  of  all  I  would  like  to  thcink  the  ones  who  made  this  all  worthwhile.  I  would 
like  to  thank  my  parents,  Doug  and  Jean  Cecil,  for  instilling  in  me  w  understanding  of 
the  importance  of  family  and  a  desire  to  always  learn  more.  I  would  like  to  thank  my 
daughters,  Stacy  Tean  and  Cristin  Marie  for  understanding  why  I  could  not  spend  the 
time  with  them  ey  deserved,  and  for  the  overwhelming  joy  and  pride  I  get  from  being 
their  dad.  And  i.  .dly,  I  would  like  to  thank  my  wife  Kim.  Her  understanding,  support  and 
imwavering  love  have  sustained  me  through  a  lot  in  the  past  sixteen  years.  The  sacrifices 
she  m2uie  during  this  masters  progrsun  eire  just  the  most  recent  in  our  Air  Force  ciureer.  It 
is  to  her  I  dedicate  my  work  on  this  thesis. 


Danny  A.  Cecil 


ii 


I  wish  to  thank  my  co-advisors,  Major  Mark  Roth  and  Major  Paul  Bailor  for  their 
help,  patience,  and  advice.  Through  their  efforts,.  I  learned  alot  about  general  problem 
research  techniques  as  well  sis  this  specific  research  surea.  Thsinks  to  Dr.  Potoczny  for 
being  on  my  committee.  I  would  sJso  like  to  express  my  gratitude  to  other  members  of  the 
knowledge-bsised  softwsire  engineering  group  for  sJl  of  their  help  and  support.  A  specisd 
thsmks  to  Captsun  Dsm  Cecil,  my  research  psui:ner,  and  Captsun  Jay  Cossentine  who  helped 
me  maintsun  some  sense  of  sanity  throughout  the  thesis  process. 

Finally,  I  would  like  to  thank  my  family  who  supported  me  by  imderstsinding  the 
importance  of  education.  A  specisil  thsmks  goes  to  my  daughters  Erin,  Katie,  smd  Amy. 
Their  understsmding  for  sill  the  time  I  needed  to  su:complish  this  task,  sis  well  sis  their  ability 
to  remind  me  of  the  important  things  in  life  helped  me  keep  my  priorities  in  line.  And 
most  of  all,  I  want  to  thank  my  wife  and  best  firiend,  Julie,  for  sdl  the  personsJ  ssu:rifices  she 
made  for  me.  Her  love,  imderstsmding,  encouragement,  smd  fsuth  throughout  this  AFIT 
progrsim,  smd  sJl  my  endeavors,  keeps  me  going  through  all  life’s  difi^culties  smd  triiunphs. 

Joseph  A.  FuUenkamp 


iii 


Table  of  Contents 


Page 

List  of  Figures .  ix 

Abstract .  xii 

I.  Introduction .  1-1 

1.1  Overview .  1-1 

1.2  Background .  1-1 

1.3  Problem .  1-6 

1.4  Scope .  1-7 

1.5  Approach .  1-7 

1.6  Summary .  1-8 

1.7  Order  of  Presentation .  1-8 

II.  Literatiure  Review  .  2-1 

2.1  Introduction .  2-1 

2.2  Domain-Oriented  Application  Composition  Terminology  ...  2-1 

2.3  Object-Oriented  Approach  and  Modeling .  2-3 

2.3.1  Definition  of  Terms .  2-4 

2.3.2  Object  Model  Notation .  2-5 

2.4  Background  on  Object-Oriented  Database  Management  Systems  2-6 

2.5  Evolution  of  Database  Technology .  2-7 

2.6  The  Current  State  of  Object  Technology  .  2-9 

2.6.1  Object-Oriented  Database  Programming  Languages  2-11 

2.6.2  Extended  Relational  Database  Management  Systems  2-11 

2.7  Conclusion .  2-12 

iv 


Page 

III.  Operational  Concepta  and  Requirements  Identification .  3-1 

3.1  Overview .  3-1 

3.2  Architect  Operational  Overview .  3-3 

3.2.1  Key  People  Interacting  With  Architect .  3-5 

3.2.2  Key  Components  of  Architect .  3-5 

3.2.3  Functionality  of  Architect .  3-10 

3.3  Requirements  Analysis  Results .  3-10 

3.4  OODBMS  Comparison  .  3-13 

3.4.1  Matisse  .  3-13 

3.4.2  ObjectStore .  3-14 

3.4.3  Itasca .  3-15 

3.4.4  Selection  of  an  OODBMS .  3-16 

3.5  Conclusion .  3-16 

IV.  Design  and  Implementation  of  an  OODBMS  Technology  Base .  4-1 

4.1  Introduction .  4-1 

4.2  Selection  of  a  Validating  Domain .  4-1 

4.2.1  Identification  of  Artifacts  in  Selected  Domain  ....  4-2 

4.2.2  Development  of  Object  Model  for  Selected  Domsiin  .  4-3 

4.3  Database  Communications  Platform .  4-5 

4.3.1  ToolTalk  .  4-6 

4.3.2  Itasca’s  Remote  Lisp  API .  4-7 

4.3.3  Conclusion .  4-8 

4.4  Target  Architectiu'e  Description .  4-8 

4.4.1  Object-Connection-Update  (OCU)  Architectiure  .  .  .  4-8 

4.4.2  OCU  Object  Model  Development .  4-9 

4.5  Incorporation  of  Itasca  in  AVSI .  4-10 

4.5.1  Backgroimd .  4-12 


V 


Page 

4.5.2  Saving  Composed  Applications  into  ITASCA .  4-15 

4.5.3  Loading  Composed  Applications  from  ItasCA  ....  4-17 

4.6  Domain-Definition  Object  Model  Development .  4-17 

4.6.1  Abstraction  of  Domsun-Oriented  Object  Modeb  .  .  .  4-17 

4.6.2  Populating  Database  with  Domain  Knowledge  .  .  .  4-25 

4.6.3  Automatic  Generation  of  Database  Schema .  4-25 

4.6.4  Automatic  Generation  of  Refine  Source  Code  .  .  .  4-27 

4.7  Incorporation  of  Concurrent  Rese2urch  Results .  4-28 

4.7.1  Changes  for  the  Visual  Interface .  4-28 

4.7.2  Addition  of  Application  Executive  Services .  4-28 

4.8  Conclusion .  4-28 

V.  Validation  and  Analysis .  5-1 

5.1  Introduction .  5-1 

5.2  Testing  of  AVSI  with  Database  Capabilities .  5-1 

5.3  Testing  of  Database  Methods .  5-3 

5.3.1  Testing  Methods  that  Generate  Database  Schemeis  .  5-3 

5.3.2  Testing  Methods  that  Generate  Refine  Source  Code  5-4 

5.4  Testing  of  Integrated  System .  5-4 

5.5  Validating  Support  for  Concurrent  Research  Results .  5-5 

5.6  Conclusion .  5-5 

VI.  Conclusions  and  Recommendations .  6-1 

6.1  Conclusions .  6-4 

6.2  Recommendations  for  Further  Research .  6-5 

6.3  Final  Comments .  6-6 


vi 


Page 

Appendix  A.  Description  of  Technology  Base  Primitives  for  Logic  Circuits 

Domain .  A-1 

A.l  Description  of  Data  Collection  Forms .  A-1 

A. 2  Completed  Data  Collection  Forms  for  the  Logic  Circuits  Domain  A-6 

Appendix  B.  Code  Automatically  Generated  By  ITASCA  Methods .  B-1 

B. l  Database  Schema  Generated  By  Itasca  Methods .  B-1 

B. 2  Refine  Source  Code  Generated  By  ITASCA  Methods  ....  B-4 

Appendix  C.  Technology  Base  Applications  from  Logic  Circuits  Domaun  .  C-1 

C. l  TEST  Application .  C-1 

C.2  ADDER  Application .  C-2 

C.3  DECODERl  Application .  C-5 

C.4  ADD-AND-DECODE  Application .  C-6 

C.5  ADD-AND-DECODE2  AppUcation .  C-14 

C.6  BCD- ADDER  AppUcation .  C-22 

C.7  BINARY-ARRAY-MULTIPLIERl  AppUcation .  C-32 

C.8  BINARY-ARRAY-MULTIPLIER2  AppUcation .  C-35 

C. 9  THREE-TO-EIGHT-DECODER  AppUcation .  C-38 

Appendix  D.  Sample  Session  :  Populating  OODBMS  With  Domain  Knowl¬ 
edge  .  D-1 

D. l  Steurt  a  Session .  D-4 

D.2  Instantiate  Instances  of  the  DATA-OBJECT  Class .  D-5 

D.3  Instantiate  Instances  of  the  REFINE-FUNCTION  Class  .  .  .  D-10 

D.4  Instantiate  Instances  of  the  ABSTRACT  Class .  D-12 

D.5  Instantiate  Instances  of  the  CONCRETE  Class .  D-14 

D.6  Instantiate  Instances  of  the  DOMAIN-DEF  Class  .  D-15 


vii 


Page 

Appendix  E.  Sample  Session  :  OODBMS  Implementation  of  Technology  Base  E)-l 

E.l  Start  AVSI .  E-1 

E.2  Create  a  New  Application .  E-2 

E.3  Edit  the  Application .  E-2 

E.3.1  Add  the  Controlling  Subsystem-obj  to  the  Application  £}-2 
E.3.2  Create  the  Application-obj’s  Update  Algorithm  .  .  .  E-3 

E.4  Edit  the  Subsystems .  E-4 

E.4.1  Add  the  Subsystem  .  E-4 

E.4.2  Add  the  Primitive  Objects  .  E-5 

E.4. 3  Connect  LIGHT’s  Imports  and  Exports .  E3-5 

E.4.4  Build  THE-LIGHT’s  Update  Algorithm .  E-6 

E.5  Perform  Semantic  Checks .  E-6 

E.6  Execute  the  Application .  E-7 

E.7  Save  the  Application  to  the  Database .  EJ-7 

E.8  Delete  the  Application  from  the  Database .  E}-8 

Bibliography .  BIB-1 

Vita .  VITA-1 


viii 


List  of  Figures 


Figure  Page 

1.1.  J-MASS  Configxiration .  1-2 

1.2.  J-MASS/ Architect  Integration .  1-3 

2.1.  Relationship  of  Model-Based  Software  Development  Terms .  2-2 

2.2.  Object  Modeling  Notation .  2-6 

2.3.  Relational  Database  Tables  .  2-8 

3.1.  Domain-Oriented  Application  Composition  Environment .  3-2 

3.2.  Architect  1.0  -  Domain-Oriented  Application  Composition  System  .  .  .  3-4 

3.3.  OCU  Subsystem  Construction .  3-6 

3.4.  OCU  Object  and  Controller  Procedural  Interfaces .  3-7 

4.1.  Object  Model  of  Logic  Circuits  Dommn .  4-4 

4.2.  Alternate  Object  Model  of  Logic  Circuits  Domain .  4-6 

4.3.  Object  Model  of  Object-Connection-Update  (OCU)  Architecture  .  .  .  4-10 

4.4.  Combined  Object  Models  Showing  Circuits  Inheriting  from  OCU  .  .  .  4-11 

4.5.  AVSI  Instance  Diagr2ma  for  Light  Application .  4-13 

4.6.  Itasca  Instance  Diagraim  for  Light  Application .  4-15 

4.7.  Domain-Definition  Object  Model .  4-18 

4.8.  Refine  Code  for  Update  Function .  4-23 

4.9.  Domain-Definition  Instance  Diagram  for  Logic  Circuits  Domain  Subset  4-24 

4.10.  Itasca  Schema  Template  .  4-26 

4.11.  Itasca  Class  Definition  of  CIRCUITS  Class .  4-26 

4.12.  Itasca  Class  Definition  of  the  GATE  Class .  4-27 

6.1.  Big  Picture  of  the  New  Architect  Environment .  6-2 

A.l.  Data  Collection  Form  for  DOMAIN-DEF  Class .  A-1 

ix 


Figure  Page 

A.2.  Data  Collection  Form  for  OBJECT-CLASS  Claes .  A-2 

A.3.  Data  Collection  Form  for  OCU  Attributes .  A-3 

A.4.  Data  Collection  Form  for  OCU  Constants .  A-3 

A.5.  Data  Collection  Form  for  OCU  Coefficients  .  A-4 

A.6.  Data  Collection  Form  for  OCU  Inputs .  A-4 

A.7.  Data  Collection  Form  for  OCU  Outputs .  A-5 

A.8.  Data  Collection  Form  for  OCU  Functions  .  A-5 

A.9.  Completed  Data  Collection  Form  for  DOMAIN-DEF .  A-6 

A.IO.  Completed  Data  Collection  Form  for  Circuit-Artifact  OBJECT-CLASS  A-6 

A.ll.  Completed  Data  Collection  Form  for  Component  OBJECT-CLASS  .  .  A-7 

A. 12.  Completed  Data  Collection  Form  for  Gate  OBJECT-CLASS .  A-7 

A. 13.  Completed  Data  Collection  Form  for  Switch  OBJECT-CLASS .  A-8 

A.14.  Completed  Data  Collection  Form  for  LED  OBJECT-CLASS .  A-8 

A. 15.  Completed  Data  Collection  Form  for  And-Gate  OBJECT-CLASS  .  .  .  A-9 

A.16.  Completed  Data  Collection  Form  for  Or-Gate  OBJECT-CLASS  ....  A-9 

A.17.  Completed  Data  Collection  Form  for  Nand-Gate  OBJECT-CLASS  .  .  A-10 

A. 18.  Completed  Data  Collection  Form  for  Nor-Gate  OBJECT-CLASS  .  .  .  A-10 

A.19.  Completed  Data  Collection  Form  for  Not-Gate  OBJECT-CLASS  .  .  .  A-11 

A.20.  Completed  Data  Collection  Form  for  Counter  OBJECT-CLASS  ....  A-11 

A.21.  Completed  Data  Collection  Form  for  Multiplexer  OBJECT-CLASS  .  .  A-12 

A.22.  Completed  Data  Collection  Form  for  Half-Adder  OBJECT-CLASS  .  .  A-12 

A.23.  Completed  Data  Collection  Form  for  Decoder  OBJECT-CLASS  ....  A-13 

A.24.  Completed  Data  Collection  Form  for  JK-Flip-Flop  OBJECT-CLASS  .  A-13 

A.25.  Completed  Data  Collection  Form  for  Attributes .  A-14 

A.26.  Completed  Data  Collection  Form  for  Constants .  A-14 

A.27.  Completed  Data  Collection  Form  for  Coefficients .  A-15 

A.28.  Completed  Data  Collection  Form  for  OCU-Inputs .  A-15 


X 


Figlire  Page 

A.29.  Completed  Data  Collection  Form  for  OCU-Outputs .  A-16 

A.30.  Completed  Data  Collection  Form  for  REFINE-FUNCTION .  A-16 

A.31.  Completed  Data  Collection  Form  for  REFINE-FUNCTION .  A-17 

D.l.  Sample  Subset  of  Logic  Circuits  Domain .  D-2 

D.2.  Instance  Diagram  for  Sample  Subset  of  Logic  Circmts  Domain .  D-3 

D.3.  ITASCA  ADE .  D-4 

D.4.  Selecting  the  DATA-OBJECT  Class .  D-5 

D.5.  Instantiating  the  Manufacturer  Attribute .  D-6 

D.6.  Instantiating  the  MilSpec?  Attribute .  D-6 

D.7.  Instantiating  the  Delay  Attribute .  D-7 

D.8.  Instantiating  the  PowerLevel  Attribute .  D-7 

D.9.  Instantiating  the  Tnl  Input .  D-8 

D.IO.  Instaoitiating  the  In2  Input .  D-8 

D.ll.  Instantiating  the  Outl  Output .  D-9 

D.12.  Selecting  the  REFINE-FUNCTION  Class  .  D-10 

D.13.  Instcintiating  the  REFINE-FUNCTION  Class  for  Updatel .  D-11 

D.14.  Instantiating  the  REFINE-FUNCTION  Class  for  Update2 .  D-11 

D.15.  Selecting  the  ABSTRACT  Class .  D-12 

D.16.  Instantiating  the  ABSTRACT  Class  for  Circuit-Artifact .  D-13 

D.17.  Instantiating  the  ABSTRACT  Class  for  Gate .  D-13 

D.18.  Selecting  the  CONCRETE  Class  .  D-14 

D.19.  Instantiating  the  CONCRETE  Class  for  And-Gate .  D-14 

D.20.  Selecting  the  DOMAIN-DEF  Class .  D-15 

D. 21.  Instantiating  the  DOMAIN-DEF  Class  for  Circuits  Domain .  D-16 

E. l.  Light  Circuit .  EM 

E.2.  OCU- APPLICATION  Transaction .  E-8 

xi 


AFIT/GCS/ENG/93D-03 


Abstract 

This  research  designed  and  prototyped  tin  OODBMS  technology  base  to  store  and 
retrieve  various  types  of  domain  artifacts  for  domain-oriented  application  composition 
systems  (DOACS).  We  developed  object-oriented  database  schemas  for  a  validating  domain 
and  the  Object-Connection-Update  software  architecture.  We  implemented  an  inheri¬ 
tance  relationship  between  the  schemas  so  a  domain  model  can  inherit  an  architectural 
structure  from  an  architectiu'e  model  allowing  us  to  isolate  domain-specific  knowledge 
from  curchitecture-specific  knowledge.  We  eJso  developed  a  meta-model  to  formally  define 
domain  models  in  the  database.  We  then  developed  a  set  of  database  methods  to  trzmsform 
a  domain  model  into  a  database  schema  for  storing  artifacts  from  the  domain  and  to 
automatically  populate  the  DOACS  object  base  with  the  domain  definition.  Using  an 
OODBMS,  the  structure  and  relationships  that  provide  much  of  the  power  in  object  models 
are  retained  because  the  artificial  flattening  required  for  storage  in  traditional  databases 
and  file  systems  is  prevented.  Isolating  domain  and  architecture  models  firom  each  other 
htis  greatly  increased  the  reusability  of  the  domain  artifacts,  the  domain  model,  and  the 
architecture  model.  The  inheritance  relationship  between  dom2un  and  architecture  models 
allows  a  dommn  to  be  defined  once,  but  used  in  many  different  architectural  environments 
and  vice  versa. 


Using  Database  Technology  to  Support  Domain-Oriented  Application  Composition 

Systems 


I.  Introduction 

1.1  Overview 

The  primary  piupose  of  this  research  effort  was  to  examine  the  capabilities  and 
benefits  of  using  object-oriented  database  management  system  (OODBMS)  technology 
in  support  of  model-based  software  development  (MBSD).  This  research  focused  on  a 
prototype  domain-oriented  application  composition  system  developed  by  previous  research 
at  AFIT  (1,  26,  35),  and  explored  the  potential  services  an  OODBMS  could  provide. 

1.2  Background 

“The  [Joint  Modeling  and  Simulation  System]  J-MASS  program  is  intended  to  pro¬ 
vide  a  flexible,  standardized,  and  validated  modeling  tool  to  support  a  wide  range  of  simu¬ 
lation  requirements  across  the  life  cycle  of  a  weapon  system”  (2).  The  major  components 
of  the  J-MASS  architecture,  shown  in  Figure  1.1,  are  the  Simulation  Support  Environment 
(SSE)  2ind  the  Modeling  Libr2iry.  The  SSE  serves  as  the  user  interface  to  J-MASS,  while 
the  Modeling  Library  serves  sis  a  central  repository  for  software  simrilation  components  to 
be  used  in  J-MASS  simulations.  To  date,  research  at  the  Air  Force  Institute  of  Technology 
(AFIT)  has  concentrated  on  the  Develop  Components  and  Assemble  Players  capabilities 
of  the  J-MASS  SSE. 

The  Architect  system,  developed  at  AFIT  by  Randour  (26),  Anderson  (1),  and 
others,  serves  as  a  proof-of-concept  for  an  advanced  Develop  Components  and  Assemble 
Players  capability  in  the  J-MASS  SSE.  Additionally,  Anderson  and  Randour’s  work  cein 
be  extended  to  provide  rudimentary  Configure  and  Execute  Simrilation  capabilities  for 
J-MASS.  The  shaded  portion  in  the  top  half  of  Figure  1.2  shows  the  J-MASS  capabilities 
that  Architect  currently  provides.  Note,  too,  that  the  bottom  half  of  Figure  1.2  shows  the 
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MODELING  LIBRARY 

Figure  1.1  J-MASS  Configuration  :  zulapted  from  (2) 

portion  of  the  modeling  library  implemented  using  an  OODBMS,  and  this  is  the  primary 
focus  of  our  research  effort.  Heillor3in’s  research  (12)  at  AFIT  investigates  the  use  of 
an  OODBMS  for  the  remaining  (dynamic)  portion  of  the  modeling  library.  Architect  is 
a  prototype  system  designed  to  allow  a  software  engineer  and  application  specialist  to 
work  together  to  compose  formally  specified  software  artifacts  into  formed  software  system 
specifications.  Anderson  and  Randour  used  the  logic  circuits  domeun  as  their  validating 
domain  for  Architect.  They  created  primitive  objects  common  to  the  logic  circuits  domeiin 
such  as  AND,  OR,  NAND,  NOR,  and  NOT  gates  as  well  as  switches  and  LEDs  (light 
emitting  diodes).  Using  these  primitives  and  others,  they  demonstrated  the  ability  to 
compose  these  artifacts  into  specifications  of  more  complex  artifacts  in  the  logic  circuits 
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MODELING  LIBRARY 

Figure  1.2  J-M ASS/ Architect  Integration  :  adapted  from  (2) 


domain  such  as  half-adders,  decoders,  and  binary-array  multiphers.  They  cilso  used  the 
specifications  of  these  artifacts  to  compose  applications  to  test  the  functionality  of  the 
artifacts  they  had  developed. 

The  primitives,  components  composed  of  primitives,  and  applications  composed 
of  primitives  and  other  components  2ire  all  examples  of  the  types  of  eirtifacts  that  the 
technology  base  for  the  logic  circuits  domain  must  store.  In  the  avionics  dommn,  an 
artifact  may  be  an  aileron  or  a  rudder  ^lnd  a  system  composed  using  those  might  be  the 
mrframe  of  ein  aircr2ift.  The  eirchitectureil  model  used  by  Randour  and  Anderson  is  the 
Object-Connect-Update  (OCU)  model  developed  at  the  Software  Engineering  Institute 
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(SEl)  (19).  The  technology  base  needs  to  capture  the  chosen  architecture  as  well  as  any 
domain  models. 

A  primary  objective  listed  in  the  J-MASS  System  Concept  Document  (SCD)  is  “to 
provide  a  Modeling  Library  which  can  be  used  to  classify,  catalog,  and  store  software 
simulation  components  as  reusable  software"  (2).  A  key  pr2u;tice  in  engineering  is  the 
extensive  reuse  of  technical  resources  (10).  The  success  of  software  engineering  depends 
heavily  on  the  reusability  of  software  components  and  engineering  models  (knowledge),  to 
include  specifications,  domain-specific  models,  source  code,  and  documentation  (4).  To 
accomplish  this,  software  engineers  require  a  software  library.  A  software  library  is  a 
controlled  collection  of  software  resources  and  related  documentation  designed  to  aid  in 
software  development,  reuse,  and  maintenance  (25).  Traditional  database  management 
systems  (DBMSs)  cannot  fully  support  the  complex,  object-based  artifacts  that  must 
populate  the  J-MASS  Modeling  Library  (17:425-427). 

A  relatively  new  technology  in  the  field  of  database  management  is  OODBMS  tech¬ 
nology.  Cattell  states  in  his  text  that  “the  structural  properties  of  complex  objects  alone 
necessitate  the  new  . . .  [OODBMS]  technology”  (6:8).  The  complex,  object-oriented  nature 
of  the  surtifacts  to  be  stored  in  the  J-MASS  Modeling  Library  and  the  complimentary 
strengths  of  OODBMSs  warrant  an  investigation  of  OODBMS  technology  for  a  possible 
implementation  of  the  J-MASS  Modeling  Library. 

Several  factors  drove  the  decision  to  use  an  OODBMS  to  implement  portions  of  the 
J-MASS  modeling  library. 

1.  J-MASS  has  dictated  that  “the  development  approach  [for  simulation  components] 
will  be  governed  by  ...  an  object-oriented  requirements  analysis  and  design  [pro¬ 
cess]”  (2:8). 

2.  The  nature  of  the  problem  lends  itself  to  an  object-oriented  solution. 

(a)  The  simulation  components  are  modeled  as  objects. 

(b)  Simulation  objects  can  have  very  complex  structures  and  be  composed  of  other 
objects. 
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(c)  There  is  a  need  for  multiple  versions  of  the  database  and  of  individual  objects. 

(d)  According  to  Cattell  (6:15),  the  three  application  areas  most  commonly  cited  as 
benefiting  firom  OODBMSs  are  software  engineering;  mechanical  and  electrical 
engineering;  and  document  systems.  Our  “application”  deals  with  many  of  the 
same  kinds  of  artifacts  as  those  do.  For  example,  we  will  be  storing  programs  and 
program  specifications  as  software  engineering  does,  designs  as  medianical  and 
electrical  engineering  does,  and  text  and  graphics  much  like  document  systems 
do. 

3.  Three  OODBMSs  are  available  at  AFIT  for  research  efforts: 

•  Itasca’^” 

•  ObjectStore^“ 

•  Matisse™ 

Boom  and  Mallare  (21)  demonstrated  the  feasibility  of  transforming  informal  spec¬ 
ifications  (such  as  entity  relationship,  state  transition,  and  data  flow  models  of  domain 
objects)  into  formal,  mathematically-based  executable  specifications  amenable  to  manipu¬ 
lation  and  proof.  The  approach  they  took  was  first  to  translate  the  three  informal  models 
into  a  single  Unified  Abstract  Model  (UAM)  which  they  developed.  Then  they  mapped 
the  UAM  representation  of  a  portion  of  the  problem  space  to  a  formal  Object  Model¬ 
ing  Lemguage  (OML)  they  developed  for  that  purpose.  They  used  Software  Refinery’s 
Refine'^'^  to  specify  wd  execute  their  models.  Because  OML  is  formal  in  nature.  Software 
Refinery’s  language  processor,  DIALECT^”,  can  parse  OML  into  the  REFINE  Object  Base 
where  it  can  be  executed  to  simulate  the  behavior  of  the  initial  informal  specifications. 
A  user  can  make  x'.odifications  imtil  obtaining  the  expected  behavior,  thus  producing  a 
satisfactory  formzil  specification.  These  formal  object-based  specifications  can  populate  the 
Architect  Technology  Base  and,  c  ^  the  J-MASS  Modeling  Library.  They  can  then  become 
the  building  blocks  for  composing  together  simulation  components  of  use  to  J-MASS. 

There  are  a  number  of  other  systems  producing  formal  object-based  specifications 
similar  to  those  stored  in  the  Architect  technology  base.  Lockheed,  for  example,  is  doing 
work  that  may  be  integrated  with  the  Archi^^ct  system.  Lockheed’s  Environment  for 
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Automatic  Programming  (LEAP)  produces  object-based  artifacts  in  the  form  of  Common 
Intermediate  Design  Language  (CIDL)  primitives.  Research  is  underway  to  provide  a  tool 
set  necessary  to  introduce  these  specifications  into  the  Architect  system  so  the  application 
specialist  can  manipulate  them  to  produce  composite  systems  (30). 

Diuring  the  life  cycle  of  an  application  being  developed  with  Architect,  the  application 
specialist  can  define  objects  at  varying  levels  of  abstraction.  Actual  target  language  code 
fragments;  intermediate  design  languages  like  OML,  CIDL,  and  REFINE;  and  informal 
graphical  models  are  examples  of  different  levels  of  abstraction  that  the  application  spe¬ 
cialist  can  use.  Dining  any  given  Architect  session,  objects  from  a  peurticular  application 
domain,  zmd  other  closely  related  domains,  may  populate  the  technology  base.  These 
objects  can  range  in  complexity  from  simple  to  very  complex.  During  the  prototyping  of 
an  application,  many  versions  of  objects  may  be  developed.  Many  different  instances  of  the 
technology  base,  representing  many  diverse  domuns,  may  need  to  be  maintained  between 
Architect  sessions.  The  result  is  voluminous  amounts  of  complex  object-based  models  that 
need  to  be  maintained. 

OML,  CIDL,  Refine,  and  Ada  code  are  all  abstract  representations  of  complex 
objects  that  J-MASS  could  use  and  the  J-MASS  Modeling  Library  needs  to  maintain. 
To  accomplish  this,  we  must  produce  a  common,  object-based  representation  capable  of 
modeling  these  complex  objects.  The  schema  of  an  OODBMS  implementation  can  then 
use  this  common  representation. 

1.3  Problem 

To  date,  research  at  AFIT  has  concentrated  on  the  “develop  components”  and 
“assemble  players”  capabilities  of  the  SSE,  producing  models  that  the  modeling  library 
needs  to  maintain.  The  next  logical  step  in  the  J-MASS  research  effort  is  to  develop  a  set 
of  unified  models  to  represent  the  data  and  objects  described  above.  These  models  can 
help  “bridge  the  gap”  between  Architect,  LEAP,  and  other  closely  related  systems;  and  an 
OODBMS  can  store  these  artifacts  for  the  systems  to  sh2u:e. 
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Problem  Statement: 

Use  OODBMS  technology  to  develop  a  Modeling  Library  that  can  classify,  catalog, 
and  store  complex,  object-oriented  software  simulation  components  as  reusable  soft¬ 
ware  artifacts.  The  Modeling  Library  must  be  able  to  manage  simulation  artifacts 
produced  and  consumed  by  J-MASS,  ARCHITECT,  and  LEAP. 

1.4  Scope 

Boom  and  Mallare  (21)  demonstrated  the  capability  to  transform  informal  analysis 
and  design  models  into  an  object  modeling  language  (OML),  and  then,  in  turn,  convert 
that  into  a  formal  executable  specification.  Therefore,  this  research  does  not  focus  on  the 
translation  process  of  levels  of  abstraction.  Instead,  it  provides  a  common  repository  for 
artifacts  defined  at  various  levels  of  abstraction  by  multiple  sources  that  are  accessible  to 
many  applications  and  users. 

In  this  research  we  focused  on  the  static  portion  of  the  J-MASS  Modeling  Library 
as  depicted  in  Figure  1.2.  We  made  no  attempt  to  support  the  execution  of  an  active 
simiilation  in  the  OODBMS  environment,  as  this  is  the  focus  of  other  AFIT  research  (12). 

There  were  three  OODBMSs  available  at  AFIT.  They  were  Itasca,  Matisse,  and 
ObjectStore.  The  developers  of  each  of  these  OODBMSs  added  DBMS  featiures  to 
an  existing  object-oriented  programming  language.  The  other  approach  to  OODBMS 
development  is  to  add  object-oriented  capabilities  to  an  existing  traditional  DBMS.  We 
only  considered  the  OODBMSs  currently  available  at  AFIT  for  our  Modeling  Library 
implementation. 

1.5  Approach 

The  goal  of  this  reseaurch  was  to  implement  a  prototype  of  the  static  portion  of  the 
J-MASS  Modeling  Librauy  using  OODBMS  technology.  The  steps  needed  to  accomplish 
this  goal  follow: 

•  Conduct  a  literature  search  for  parallel  research  efforts  to  aid  in  selecting  the  best 
OODBMS  and  developing  a  database  schema  for  this  problem. 
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•  Identify  the  types  of  artifacts  we  want  to  store  in  the  object-base  and  develop  storage 
and  retrieval  tests  to  execute  against  the  finished  product. 

•  Analyze  the  artifacts  and  develop  object  model  representations  for  them. 

•  Identify  the  characteristics  needed  in  an  OODBMS  for  storing  the  artifacts  identified 
above. 

•  Select  Itasca'^“,  ObjectStorb^“,  or  Matisse'^“  based  on  the  above  listed  charac¬ 
teristics. 

•  Investigate  ways  to  provide  a  standard  communication  interface  that  allows  various 
toob  in  an  domain-oriented  application  composition  environment  to  use  a  database 
version  of  a  technology  base. 

•  Implement  the  technology  base  design  in  the  chosen  environment. 

•  Load  the  technology  base  with  the  artifacts  identified  above. 

•  Execute  the  test  cases  developed  earlier  to  store,  manipulate,  and  retrieve  artifacts 
in  the  Modeling  Library. 

1.6  Summary 

This  research  focused  on  a  specific  problem  in  a  specific  application  area:  managing 
complex,  object-based  artifacts  for  systems  like  J-MASS.  We  can  generalize  a  solution  to 
this  specific  problem,  however,  and  apply  it  to  a  whole  class  of  similar  problems.  Computer 
aided  software  engineering  (CASE),  computer  aided  design  (CAD),  hypertext,  and  oflice 
information  systems  (CIS )  all  manage  complex  objects  in  a  dynamic  environment.  Tradi¬ 
tional  DBMSs  are  not  meeting  the  needs  of  J-MASS  and  similar  systems.  Object-oriented 
database  management  system  technology  has  the  potential  to  meet  these  needs.  This 
research  helps  identify  the  strengths  and  weaiknesses  of  OODBMS  technology  for  solving 
this  class  of  problems. 

1.7  Order  of  Presentation 

The  remainder  of  this  thesis  is  organized  as  follows: 
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Chapter  11  provides  a  review  of  available  literature  concerning  model-based  software 
development  and  object-oriented  database  systems,  and  reasons  why  they  should  be  com¬ 
bined. 

Chapter  III  discusses  the  implementation  of  an  application  composition  system  we 
modified,  the  operational  concept  for  developing  technology  bases  using  OODBMS  tech¬ 
nology,  and  our  planned  objectives. 

Chapter  IV  examines  our  design  and  implementation  methods  used  for  this  research 
effort. 

In  Chapter  V  we  discuss  our  objectives  for  validating  the  correctness  of  our  work,  as 
well  as  reporting  our  test  results. 

Finzdly,  Chapter  VI  summarizes  our  accomplishments  and  outlines  recommendations 
for  future  research  in  this  area. 
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II.  Literature  Review 


2.1  Introduction 

Before  discussing  what  object-oriented  database  management  systems  (OODBMS) 
are  and  what  benefits  they  hold  for  us,  it  is  first  necessary  to  define  the  application  domain 
we  worked  with.  We  begin  by  defining  some  of  the  terminology  needed  to  disoiss  domain- 
oriented  application  composition  environments.  We  follow  this  with  justification  for  iising 
an  object-oriented  approach,  and  a  description  of  the  object  modeling  technique  we  used 
to  describe  the  objects  stored  in  the  database.  Finally,  we  investigate  the  evolution  of 
OODBMS  technology  to  its  current  state,  and  discuss  its  applicability  to  model-based 
software  development. 

2.2  Domain-Oriented  Application  Composition  Terminology 

Anderson  (1)  and  Randour’s  (26)  researdi  focused  on  the  development  of  a  domain- 
oriented  application  composition  system  to  help  bixild  up  a  technology  base  for  software 
development.  They  discussed  how  this  reusable  technology  base  could  help  bring  a  more 
traditional  engineering  mind-set  to  the  evolving  software  engineering  discipline.  Rather 
than  duplicate  their  justifications  and  conclusions,  we  only  provide  definitions  for  some  of 
the  terminology  we  used  as  we  developed  an  object-oriented  database  extension  to  their 
work. 

The  Software  Engineering  Institute  published  a  special  report  on  model  based  soft¬ 
ware  development.  They  defined  the  following  terms  eind  the  relationships  between  them 
as  shown  in  Figure  2.1  (19): 

•  Technology  Base  -  A  set  of  models,  and  rules  for  their  composition,  designed  and 
created  with  the  same  engineering  goals  in  mind.  That  is,  the  engineering  goals 
provide  a  common,  imderlying  basis  for  the  models.  The  technology  base  contains 
both  product  and  practice  models. 

•  Model  -  A  scalable  unit  of  reusable  engineering  experience  or  knowledge.  A  model 
is  supported  by  specification  forms  and  implementation  templates  which  provide  an 
indication  of  its  structure,  performance,  and  behavior.  Models  are  constructed  in  the 
context  of  engineering  goals. 
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Figure  2.1  Relationship  of  Model-Based  Software  Development  Terms  (adapted  from 

(19)) 


•  Engineering  Goals  -  Overriding  considerations  in  the  design  and  construction  of 
engineered  products.  For  softw8u:e  engineering,  goals  may  include:  maintainability, 
enhanceability,  composability,  and  so  on. 

•  Architecture  -  A  style  of  design.  An  architecture  is  a  selection,  from  a  technology 
base,  of  models  and  composition  rules  that  defines  the  structure,  performance,  and 
use  of  a  system  relative  to  a  set  of  engineering  rules. 

•  Design  -  A  composition  resulting  from  the  application  of  an  architecture  to  describe 
a  problem.  The  design  has  its  structure  and  performance  expressed  by  the  model  set 
comprising  an  architecture. 

•  Implementation  -  The  softw2ire  product  (a  specific  instance  of  a  design). 
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A  Domain  Engineer,  highly  knowledgeable  in  a  specific  domain,  can  captme  knowl¬ 
edge  of  the  domain  in  the  form  of  domain  models.  These  domain  models  can  be  combined 
with  an  architecture  model  to  design  and  implement  software  products  in  a  given  target 
language.  The  reuse  of  models  in  the  design  and  implementation  stages  is  consistent 
with  other  classical  engineering  disciplines  (10).  Models  can  be  abstracted  to  varying 
levels  of  detail.  Anderson  and  Randour’s  work  (1,  26)  identified  an  approach  that  allows 
sophisticated  end  users,  called  Application  Specialists,  to  compose  applications  within  a 
given  domain  using  pre-defined  domain  models.  The  approach  Anderson  and  Randour 
describe  is  a  domain-oriented  application  composition  system.  Objects  and  composition 
rules  are  maintained  as  executable,  formal  specifications  in  the  object  base,  providing 
Software  Engineers  and  Application  Specialists  with  the  ability  to  rapidly  prototype  and 
validate  desired  system  behaviors  without  first  having  to  build  complete  implementations 
(5).  Random:  and  Anderson  chose  to  use  an  object-oriented  approach  to  capture  abstrac¬ 
tions  of  real-world  entities  of  interest  in  the  domain  as  well  as  those  entities*  behaviors  and 
relationships. 

2.3  Object-Oriented  Approach  and  Modeling 

An  object-oriented  appro2udi  revolves  around  a  fundamental  construct,  the  object, 
which  combines  both  data  structures  (attributes)  and  behaviors  (methods)  in  a  single  entity 
(29:1).  The  main  benefit  of  object-oriented  programming  and  design  is  not  reduced  devel¬ 
opment  time.  Object-oriented  development  may,  in  fact,  take  more  time  than  conventional 
development,  because  it  is  intended  to  promote  future  reuse  and  reduce  downstream  errors 
and  maintenance  (29:9).  Other  benefits  of  Em  object-oriented  approach  are  the  ability  to 
better  model  the  world  in  which  we  live  and  work,  to  create  models  that  include  both 
physical  and  behavioral  characteristics,  and  to  protect  data  from  corruption  (7). 

Object-oriented  systems  without  Em  object  storage  mechanism  flatten  their  object 
structures  into  records  and  use  trEulitionEd  storage  Emd  databsise  mEmagers.  This  translation 
process  corrupts  the  object  model  smd  its  associated  benefits  Eu:e  lost  (7).  However,  the 
definitions,  integrity,  and  benefits  of  object  models  CEm  be  retEuned  using  object-oriented 
database  management  systems  (7). 
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2.3.1  Definition  of  Terms.  Before  discussing  object-oriented  databases,  it  is 
first  necessary  to  define  some  common  definitions  for  databases,  as  well  as  terms  and 
representations  for  object  modeling.  The  following  list  is  not  comprehensive  but  conteuns 
terms  eind  information  we  used  throughout  this  document,  and  it  is  meant  to  define  the 
framework  in  which  we  used  them. 


•  Databjise  Schema  -  The  structure  and  integrity  rules  for  application  data 
stored  in  a  database.  This  structure  is  the  DBMS  equivalent  of  the  type 
definitions  in  a  programming  language  (6). 

•  Meta-Model  -  A  model  that  describes  objects  necessary  to  define  models. 
For  instance,  we  develop  a  meta-model  to  hold  domain  model  definitions 
in  the  database. 

•  Object  Model  -  The  description  of  object  structures  in  an  object-oriented 
design  —  their  identity,  their  relationships  to  other  objects,  their  at¬ 
tributes,  and  their  operations  (29).  This  is  usually  documented  following 
some  graphical  form  such  as  an  object  diagram.  Note  that  for  object- 
oriented  databases,  the  object  model  cind  its  object  diagram  representation 
describe  the  database  schema. 

•  Object  Diagram  -  a  formal  graphical  notation  for  modeling  objects,  object 
classes,  and  their  relationships  to  one  another  (29:23). 

•  Object  Class  -  A  description  of  a  group  of  objects  with  similar  proper¬ 
ties  (attributes),  common  behavior  (operations),  common  relationships  to 
other  objects,  emd  common  sememtics  (29:22). 

•  Abstract  Class  -  A  class  that  is  not  directly  instantiable  but  has  instan- 
tiable  descendant  cljisses,  each  of  which  inherit  the  attributes,  operations, 
and  relationships  of  the  peurent  abstract  clas8(es)  (29:61-62).  These  are 
normally  used  to  define  cheiracteristics  that  will  be  inherited  by  more  than 
one  subclass.  An  abstract  class  must  have  at  least  one  concrete  subclass, 
that  is,  it  cannot  be  the  leaf  of  an  inheritance  tree. 

•  Concrete  Class  -  A  cleiss  that  is  instantiable.  That  is,  it  can  have  direct 
inst£mces  (29:61).  A  concrete  class  may  have  abstract  subclasses  (but  they 
in  tiun  must  have  concrete  descendants).  Only  concrete  classes  can  be  leaf 
clztsses  in  an  inheritance  tree. 

•  Instance  -  A  single  insteintiation  of  an  object  belonging  to  an  object 
class.  Eeich  instzmce  has  its  own  attribute  values  and  relationships  to 
other  instances  of  objects. 

•  Attribute  -  A  pure  data  value  (not  an  object)  held  by  the  objects  in  a 
cIeiss  (i.e.,  name,  age,  and  weight  are  attributes  of  Person  objects,  and 
color,  weight,  Eind  model-year  ^xe  attributes  of  Car  objects)  (29:23). 
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•  Association  -  Describes  a  physical  coimection  or  a  conceptual  relationship 
between  object  classes.  Often  association  names  appear  as  verbs  (29).  For 
example,  a  person  works- for  a  company. 

•  Multiplicity  -  Specifies  how  many  instances  of  one  class  may  relate  to  each 
instance  of  another  class  in  an  association. 

•  Ordering  -  Normally  an  cissociation  from  a  group  of  instances  of  one  class 
to  each  instance  of  another  class  can  be  thought  of  as  zm  unordered  set.  By 
specifying  that  an  association  is  ordered,  we  signify  that  order  is  important 
for  this  relationship. 

•  Aggregation  -  The  “part-whole”  or  “a-part-of  relationship  in  which  ob¬ 
jects  representing  components  of  something  are  associated  with  an  object 
representing  the  entire  assembly  (29).  This  relationship  is  also  referred  to 
as  an  “is-composed-of  relationship. 

•  Inheritance  -  An  abstraction  for  sharing  similarities  among  classes  while 
presei-ving  their  differences,  it  is  the  relationship  between  a  class  and 
one  or  more  further  refined  versions  of  it.  The  class  being  refined  is 
called  the  superclass  and  ezich  refined  version  is  called  a  subclass  (29:38- 
39).  For  example.  Airplane  is  the  superclass  of  F-16  and  B-52.  Each 
subclass  inherits  the  features  (attributes,  operations,  and  relationships) 
of  its  superclass.  For  example,  B-52  inherits  attributes  manufacturer, 
weight,  and  wing-span  from  Airplane,  as  well  as  the  operations  takeoff 
and  land.  Sometimes  ceilled  the  “is-a”  relationship  because  each  instance 
of  a  subclass  is  an  instance  of  the  superclass  as  well  (29). 


2.3.2  Object  Model  Notation.  Now  that  we  have  defined  some  of  the  terminology, 
we  present  a  description  of  the  notation  used  throughout  this  document  for  representing 
object  models.  We  used  a  subset  of  Rumbaugh’s  Object  Modeling  Technique  (OMT)  (29). 

Figure  2.2  provides  the  subset  of  OMT  notation  we  used  when  developing  our  object 
models.  Note  that  we  represented  objects  as  a  rectangle  containing  the  class  name,  and 
optionally  the  attributes  and/or  operations  defined  for  the  class.  A  speci2d  type  of  attribute 
is  the  class  attribute.  When  a  class  attribute  is  inherited,  the  attribute  definition,  eis 
well  as  the  attribute  value,  is  inherited.  With  a  non-class  attribute,  only  the  definition 
is  inherited  and  each  object  inheriting  the  attribute  csin  have  a  unique  value  for  that 
attribute.  Rumbaugh  distinguishes  ein  attribute  as  a  class  attribute  by  placing  a  $  in  front 
of  the  attribute  name  on  the  object  model.  Abstract  classes  are  shaded  to  distinguish  them 
from  concrete  clcisses. 
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Class: 


Class  Types: 


Inhcritaiioe: 


Figure  2.2  Object  Modeling  Notation  (adapted  from  (29)) 


Now  that  we  have  described  the  application  we  will  be  working  with  and  explained 
our  terminology  and  representation  method,  we  examine  how  object-oriented  database 
technology  can  be  apphed  to  it. 


2.4  Background  on  Object-Oriented  Database  Management  Systems 

Object-oriented  database  management  systems  (OODBMS)  are  a  relatively  new 
phenomenon  in  the  software  engineering  community.  As  such,  there  is  a  lack  of  stsmdards 
for  OODBMSs  to  adhere  to  and  a  lack  of  benchmarks  by  which  to  judge  them.  Many 
decision-meikers  would  hke  a  clear  pictmre  of  the  potential  benefits  and  drawbacks  of  using 
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OODBMS  technology.  Our  evaluation  of  the  ciurent  state  of  OODBMS  technology  shows 
that  there  are  two  primary  types  of  OODBMSs  in  use  today.  It  further  shows  that  cert2dn 
classes  of  applications  may  benefit  from  one  of  these  two  types. 

After  explaining  the  motivation  and  introducing  some  key  terms,  we  consider  some  of 
the  major  application  areas  driving  the  need  for  OODBMS  technology.  We  then  highlight 
some  important  characteristics  of  these  applications  to  show  how  traditional  DBMSs  cannot 
satisfy  their  demands.  A  discussion  of  the  direction  of  current  reseuch  trends  comes  next, 
followed  by  an  introduction  to  the  two  schools  of  thought  on  how  OODBMS  technology 
should  evolve. 

2.5  Evolution  of  Database  Technology 

A  DBMS  is  a  collection  of  related  data  and  a  set  of  procedures  to  access  and 
manipulate  that  data  (17:1).  DBMSs  are  very  beneficial  when  large  volumes  of  data  need 
to  be  managed  (17:1).  Trewlitionally,  developers  of  DBMSs  have  sought  to  meet  the  needs 
of  the  business  community.  They  typically  deal  with  the  type  of  data  that  simple  data 
structures  and  operations  can  represent.  For  exeimple,  a  bank  might  keep  a  record  for  each 
accoimt  holder  that  includes  the  accoimt  number,  the  member’s  name  ^lnd  social  security 
number  and  the  account  balance.  The  operations  performed  on  this  data  eire  relatively 
simple  as  well.  When  an  account  holder  withdraws  money  from  an  account,  an  operation 
is  invoked  to  reduce  the  account  balance  of  the  customer  by  the  appropriate  amount.  This 
type  of  DBMS  provides  simple  data  management  (6:2). 

There  have  been  a  number  of  data  models  and  lurchitectures  developed  over  the 
years  to  efficiently  meet  the  needs  of  traditional  database  users.  The  most  populsur  data 
model  for  commercizJ  data  processing  applications  today  is  the  relational  model  (17:53). 
A  relational  databEise  consists  of  a  collection  of  tables  of  related  data.  Figure  2.3  depicts 
tables  that  build  upon  the  banking  example  to  illustrate  how  a  relational  database  might 
store  baulking  data.  A  row  in  a  table  represents  a  relationship  between  each  of  the  columns 
in  that  row.  For  instance,  from  the  deposit  table  we  see  that  Johnson  has  an  accoimt 
numbered  101  at  the  Downtown  branch  and  his  balance  is  500  dollars.  Duplicating  a  value 
from  one  table  in  another  table  forms  a  relationship  between  the  two  tables.  For  example. 


2-7 


bzancb-Mme 


accounC-nuabez 


customez-naae 


balance 


Downtown 

101 

Johnson 

500 

Mianus 

215 

Smith 

700 

PerryridBO 

102 

Hayes 

400 

TippCily 

991 

Cedi 

1 

Dayton 

211 

Ikarter 

1000 

DEPOSrr  TABLE 


custooer-nane 

street 

customer-city 

Jones 

Main 

Hanison 

Johnson 

Abna 

PaloAKo 

Cedi 

Sixth 

Fairixim 

Davis 

Btst 

Dayton 

CUSTOMER  TABLE 


Figure  2.3  Relational  Databeise  Tables  :  adapted  from  (17:54,56) 

by  looking  up  Johnson’s  name  in  the  customer  table,  one  can  see  that  he  lives  on  Alma 
Street  in  the  city  of  P2do  Alto.  A  relational  database  management  system  (RDBMS)  can 
manage  large  volumes  of  this  simple  type  of  data. 

Some  of  the  key  characteristics  of  the  more  traditional  databases  are  that  they  store 
laurge  amotmts  of  similarly  structmred  records  with  small,  simple  data  items.  The  length 
of  a  transaction  on  the  traditional  database  is  usually  very  short,  measured  in  fractions  of 
a  second.  Once  designed  and  implemented,  the  structme  of  the  database  remains  f2urly 
static  (17:425-426).  The  treiditional  DBMSs  don’t  perform  well,  though,  in  many  relatively 
new  application  areas  including: 
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•  Computer-aided  design:  A  CAD  database  stores  data  pertzuning  to  an  engineering 
design,  including  the  components  of  the  item  being  designed,  the  interrelationship  of 
components,  and  old  versions  of  designs. 

•  Computer-aided  software  engineering:  A  CASE  tool  database  stores  data  reqtiired 
to  assist  software  developers.  These  data  include  source  code,  dependencies  among 
software  modules,  definitions  and  uses  of  variables,  and  the  development  history  of 
the  software  system. 

•  Multimedia  databases:  A  multimedia  database  contains  spatial  data,  audio  data, 
video  data,  amd  the  like.  Databases  of  this  sort  arise  from  geophysical  data,  voice 
mail  systems,  and  graphics  applications. 

•  Office  information  systems:  Office  automation  includes  workstation-based  tools  for 
document  creation  and  doctiment  retrieval,  tools  for  maintaining  appointment  cal¬ 
endars,  and  so  on.  An  OIS  database  must  allow  queries  pertaining  to  schedules, 
dociunents,  and  contents  of  documents. 

•  Expert  database  systems:  An  expert  database  system  includes  not  only  data  but  also 
explicit  rules  representing  integrity  constraints,  triggers,  and  other  knowledge  about 
the  enterprise  modeled  by  the  database. 

These  application  areas  have  made  great  gmns  in  recent  years,  due  in  paui;  to  the 
increased  capabilities  and  decreased  cost  of  computer  hardweure.  As  their  development 
evolved,  so  did  the  development  of  specialized  database  management  systems  to  meet 
their  special  needs.  The  result  has  been  the  development  of  many  stand-alone  database 
systems  that  will  not  interf8w:e  with  any  other  application.  With  networked  engineering 
workstations  becoming  more  common,  users  and  developers  are  looking  for  an  application- 
independent  DBMS  capable  of  managing  complex  objects  that  many  applications  can 
share. 

2.6  The  Current  State  of  Object  Technology 

A  discussion  of  OODBMS  technology  and  the  applications  driving  its  development 
is  now  in  order.  Something  CASE,  CAD,  OIS,  and  expert  systems  eJI  have  in  common 
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are  their  object-oriented  nature  and  hence  their  inherent  need  to  manage  complex  objects. 
A  complex  object  is  a  real  world  object  one  would  consider  to  be  a  single  object,  but  is 
composed  of  other  objects.  For  example,  a  book  is  a  complex  object  composed  of  a  table 
of  contents,  some  chapters,  a  glossary,  and  a  bibliography.  Any  one  of  those  objects  can 
be  further  decomposed  into  a  set  of  lower-level  objects.  For  instance,  a  chapter  could  be 
composed  of  peiragraphs,  a  paragraph  of  sentences,  and  so  on.  These  relationships  are  very 
difficult  and  costly  to  represent  in  traditional  DBMSs. 

Executable  code  modules,  called  methods,  are  the  implementation  of  operations  on 
a  class  of  objects  (29).  Since  the  data  inside  an  object  should  only  be  accessible  by  calling 
these  methods,  we  should  store  the  methods  together  with  the  data  objects. 

Another  major  difference  from  RDBMSs  is  that  OODBMSs  need  to  support  long- 
duration  transcictions.  In  a  CAD  or  CASE  environment,  a  designer  may  work  on  an  object 
for  hours  before  committing  the  work.  RDBMSs  cannot  easily  support  this  requirement. 

There  are  four  characteristics  generally  accepted  as  required  for  an  object-oriented 
software  approach  (29:1-4): 

1.  Identity.  Identity  means  discrete,  distingmshable  entities  csdled  objects  represent 
data.  Each  object  has  its  own  identity  independent  of  the  values  of  its  attributes. 

2.  Classification.  A  ci2iss  is  an  abstraction  for  grouping  objects  with  the  same  attributes 
and  operations.  Each  object  is  an  instance  of  a  class. 

3.  Inheritsmce.  The  sharing  zunong  classes  of  attributes  and  operations  in  a  hier2u:chical 
relationship.  A  program  can  break  a  class  into  subclasses,  esich  of  which  inherits  sdl 
the  properties  of  its  superclass. 

4.  Polymorphism.  The  same  operation  may  behave  differently  on  different  classes.  Each 
object  knows  how  to  perform  its  own  operation.  For  example,  the  display  of  a  circle 
is  different  from  the  display  of  a  squeure.  If  a  square  ^lnd  a  circle  are  subclasses  of 
a  graphics  superclass,  then  both  have  an  operation  cedled  display,  even  though  the 
implementation  is  different. 
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These  are  just  a  few  of  the  important  issues  that  the  OODBMS  field  must  address.  For  a 
more  thorough  discussion,  see  Cattell’s  text  (6:15-44). 

We  might  best  describe  the  current  state  of  the  OODBMS  field  as  a  state  of  change. 
Existing  OODBMSs  are  not  based  on  a  conunon  data  model  and  there  is  a  lot  of  re¬ 
search  and  experimentation  going  on  (28).  Two  schoob  of  thought  seem  to  be  forming 
among  the  experts  about  the  best  way  to  develop  OODBMSs  (28).  The  authors  of  ‘‘The 
Third-Generation  Database  System  Manifesto”  advocate  building  object  management  ca¬ 
pabilities  into  existing  RDBMSs  (31).  The  authors  of  “The  Object-Oriented  Database 
System  Manifesto”  on  the  other  hand  advocate  not  building  on  the  limited  RDBMS,  but 
incorporating  database  management  system  capabilities  into  object-oriented  programming 
languages  (3).  The  first  approach  seems  to  show  more  promise  for  business  applications, 
while  the  latter  seems  better  suited  for  the  new  applications  discussed  in  this  chapter.  In 
any  event,  it  appears  that  both  approaches  will  find  a  share  of  the  DBMS  market  for  some 
time  to  come  (6:2). 

2.6.1  Object-Oriented  Database  Programming  Languages.  In  1989,  a  group 
of  experts  published  “The  Object-Oriented  Database  System  Manifesto”  (3)  to  begin 
debate  over  the  definition  and  theoretical  framework  for  OODBMS.  The  consensus  of  this 
group  was  that  the  focus  should  be  on  staying  consbtent  with  the  ciurent  object-oriented 
programming  languages.  Although  there  is  a  requirement  for  database  management  system 
features  such  as  persistence  of  data,  secondary  storage  management,  concurrency,  recovery, 
and  ad  hoc  query  capability,  the  addition  of  these  featmes  should  not  result  in  any  loss  of 
capability  in  the  programming  language.  The  convenience  and  efficiency  of  one  language 
to  be  used  for  database  and  programming  operations,  and  the  cmnrent  popularity  of  the 
object-oriented  approach  in  progrsunming  are  the  strengths  in  this  approach  (6).  The 
current  lack  of  standards  to  allow  portability  of  these  systems  across  various  platforms,  and 
the  minimal  experience  and  development  effort  in  these  systems,  compared  to  RDBMSs, 
are  the  weaknesses  of  this  approach  (6:233-235). 

2.6.2  Extended  Relational  Database  Management  Systems.  In  response  to  the 
above  mentioned  approach  (3),  another  group  published  “The  Third-Generation  Data 
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Base  System  Manifesto’*  (31)  in  1990.  The  major  theme  of  this  group  was  that  although 
relational  databases  couldn’t  handle  the  needs  of  complex  applications,  extensions  could 
allow  them  to  do  so.  Although  most  critics  of  the  relational  model  point  out  the  deficiencies 
in  such  applications  as  CASE  and  CAD,  second  generation  systems  do  not  support  most 
business  data  processing  applications  all  that  well  (31:2).  The  focus  of  this  group,  then, 
is  that  everybody  requires  a  better  DBMS,  and  there  is,  in  fact,  a  smprising  consensus 
on  desired  capabilities  of  this  next  generation  of  DBMSs.  However,  it  is  important  to 
not  throw  out  all  the  lessons  learned  and  advantages  offered  by  current  systems.  Some 
object-oriented  programming  features,  such  as  inheritance  and  identity,  are  good  ideas; 
however,  the  cost  of  these  should  not  be  the  loss  of  reliability  and  data  independence. 
DBMS  access  should  only  occur  through  a  separate  query  language.  Experience  has  shown 
that  DBMSs  should  not  allow  user  programs  to  navigate  through  the  database  in  an  ad 
hoc  fashion  (31:24).  The  natural  evolution  of  existing  relational  DBMSs  to  ones  with  all 
the  capabilities  discussed  in  (31)  is  happening.  The  most  important  disagreement  this 
group  has  with  the  object-oriented  database  programming  language  group  is  a  matter  of 
implementation,  as  the  programming  language  approach  currently  violates  many  of  the 
tenets  that  make  good  database  systems. 

2. 7  Conclusion 

Although  OODBMSs  lack  the  matvirity,  experience,  and  research  that  RDBMSs  have, 
the  success  of  object-oriented  techniques  in  software  analysis,  design,  and  programming 
justifies  consideration  of  OODBMSs  when  researching  DBMS  options.  The  field  is  pro¬ 
gressing  rapidly  with  considerable  research  involving  OODBMSs  and  work  htts  begim  on 
establishing  OODBMS  standards  (23,  24). 
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III.  Operational  Concepts  and  Requirements  Identification 
3.1  Overview 

Research  has  been  ongoing  at  the  Air  Force  Institute  of  Technology  (AFIT)  to  develop 
a  domain-oriented  application  composition  system.  Anderson  and  Randour  made  great 
strides  toward  this  end  with  their  work  on  Architect  (1,  26).  Their  requirements  etnalysis 
includes  the  following  quote  from  an  article  by  Lowry  (20)  which  cleeurly  and  succinctly 
sums  up  the  philosophy  and  goals  of  domain-oriented  application  composition. 


Software  engineering  will  evolve  into  a  radically  changed  discipline.  Software 
will  become  adaptive  and  self-configuring,  enabling  end  users  to  specify,  modify 
and  maintain  their  own  software  within  restricted  contexts.  Software  engineers 
will  deliver  knowledge-based  application  generators  rather  than  unmodifiable 
application  programs.  These  generators  will  enable  an  end  user  to  inter^lctively 
specify  requirements  in  domain-oriented  terms  . . .  and  then  automatically  gen¬ 
erate  efficient  code  that  implements  these  requirements.  In  essence,  software 
engineers  will  deliver  the  knowledge  for  generating  software  rather  than  the 
software  itself. 

Although  end  users  will  communicate  with  these  software  generators  in 
domain-oriented  terms,  the  foundation  for  the  technology  will  be  formal  repre¬ 
sentations  . . .  Formal  languages  will  become  the  lingua  franca,  enabling  know¬ 
ledge-based  components  to  be  composed  into  larger  systems.  Formal  specifica¬ 
tions  is  the  interface  between  interactive  problem  acquisition  components  and 
automatic  program  synthesis  components. 

Software  development  will  evolve  from  w  art  to  a  true  engineering  disci¬ 
pline.  Software  systems  will  no  longer  be  developed  by  hand  crafting  large 
bodies  of  code.  Rather,  as  in  other  engineering  disciplines,  components  will 
be  combined  and  specialized  through  a  chain  of  value-added  enhancements. 

The  final  specializations  will  be  done  by  the  end  user.  KBSE  (knowledge-based 
software  engineering) . . .  will  not  replace  the  hiunan  software  engineer;  rather,  it 
will  provide  the  means  for  leveraging  human  expertise  and  knowledge  through 
automated  reuse.  New  sub  disciplines,  such  as  domun  analysis  and  design 
anzdysis,  will  emerge  to  formalize  knowledge  for  use  in  KBSE  components. 
(20:629-630) 

AFIT  researchers  have  already  shown  that  "application  composition  systems,  such 
as  . . .  [those  described  by  Lowry],  are  feasible”  (1:7).  They  have  also  shown  that  “non¬ 
programmers,  who  are  very  knowledgeable  about  a  particular  domain,  csin  create  quite 
sophisticated  applications  without  the  direct  assistance  of  software  professionals”  (1:7). 
This  research  effort  and  other  research  at  AFIT  (8,  11,  30,  33,  34,  36)  seek  to  build  on 
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Figure  3.1  Domain-Oriented  Application  Composition  Environment 


the  groundwork  laid  by  Random  and  Anderson,  as  well  as  Weide  (35)  who  provided  a 
visual  system  interface,  called  AVSF ,  to  support  the  Architect  domain-oriented  application 
composition  system. 

Figmre  3.1  depicts  a  domain-oriented  application  composition  environment.  It  sup¬ 
ports  not  only  a  domain-oriented  application  composition  system  like  Architect,  but  also 
tools  that  can  interact  with  Architect  to  create  a  more  productive  software  engineering 
environment.  Architect  is  a  specific  instance  of  the  application  composer  pictured  in  the 
lower  left-hand  comer  of  the  figure.  An  investigation  of  the  Technology  Base  Extender 

^The  terms  “Architect"  and  “AVSI"  both  refer  to  the  baseline  system  we  extended,  and  may  be  used 
interchangeably  throughout  this  document 
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(upper  left-hand  corner  of  Figure  3.1)  was  conducted  by  S2uidy  (30)  juid  Waumer  (34).  The 
Elicitor-Harvester  (upper  right-hand  comer  of  Figvire  3.1)  is  the  subject  of  future  research. 

The  primary  concern  of  this  thesis  effort  is  to  provide  an  OODBMS  implementation 
of  the  technology  base  shown  in  the  lower  right-hamd  comer  of  Figure  3.1  and  to  investigate 
the  best  means  to  provide  a  functional  backplane  interconnect  shown  in  the  center  of  the 
figure.  To  make  such  a  domain-oriented  application  composition  environment  a  reality, 
the  technology  base  must  manage  laurge  volumes  of  data  representing  knowledge  about 
multiple  domauns  amd  software  architectures  as  well  ais  software  artifacts  developed  in  the 
environment.  If  we  expect  to  get  maodmum  reuse  of  domauns,  architectures,  amd  software 
artifau:ts  developed  in  the  domaun-oriented  application  composition  environment,  we  must 
have  a  well-defined  standard  interfawre,  allowing  other  tools  to  access  the  environment  easily. 

This  chapter  addresses  the  issues  involved  in  providing  the  services  required  of  a  tech¬ 
nology  base  amd  how  to  madce  those  services  avaulable  to  client  tools  in  a  domaun-oriented 
application  composition  environment.  As  mentioned  before,  our  work  revolves  aroimd 
extending  Architect  version  1.0,  so  we  begin  in  Section  3.2  by  describing  it  amd  showing 
how  it  functioned  ais  a  stand-adone  domaun-oriented  application  composition  system.  In 
Section  3.3  we  identify  the  requirements  amd  goads  we  set  for  omrselves,  baised  on  oir 
amadysis  of  Architect  1.0  amd  oir  requirements  anadysis  for  a  domain-oriented  application 
composition  environment.  Finally,  Section  3.4  covers  am  amadysis  of  the  object-oriented 
databaise  mamagement  systems  avaulable  to  us  at  the  staui;  of  our  reseaurch,  a^  well  as  the 
rationade  for  oiu:  selection. 

3.2  Architect  Operational  Overview 

Figure  3.2  is  a  system-level  view  of  the  Architect  version  1.0  domaun-oriented  applica¬ 
tion  composition  system,  amd  the  environment  in  which  it  was  used.  To  prepaure  Architect 
for  use  in  a  pauticidax  domain,  an  expert  in  that  domaun  (Domaun  Engineer)  performs 
a  domaun  anadysis  to  identify  those  components  needed  to  build  softwaire  applications  in 
that  domaun.  The  Softwaure  Engineer,  using  knowledge  of  softwaure  architectures,  formalizes 
this  domaun  knowledge  into  a  domaun  model  with  a  set  of  primitive  components.  The 
Application  Speciadist  cam  then  start  a  session  in  Architect,  at  which  time  adl  the  pre-defined 
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Figure  3.2  Architect  1.0  -  Domain-Oriented  Application  Composition  System 

domains  stored  in  the  Persistent  Technology  Base  get  loaded  into  the  Working  Technol¬ 
ogy  Base.  Through  the  visuzd  interface  (35),  the  Application  Specialist  can  maniptdate 
domain  primitives  to  compose  and  execute  domain-oriented  application  specifications. 
The  Application  SpecizJist  can  2dso  save  newly  composed  applications  to  and  restore 
saved  applications  from  the  Persistent  Technology  Base  through  the  visual  interface.  The 
contents  of  the  Working  Technology  Base  are  not  persistent  between  Architect  sessions,  so 
any  work  the  Application  Specialist  wants  to  keep  must  be  saved  using  the  visual  system. 
In  the  remainder  of  this  section  we  look  in  more  detail  at  the  key  people  and  components 
shown  in  Figure  3.2  and  introduced  above. 
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3.2.1  Key  People  Interacting  With  Architect. 


3. 2. 1.1  Domain  Engineer.  A  Domain  Engineer  possesses  detailed  knowl¬ 
edge  about  a  domain  and  gathers  all  the  information  pertinent  to  solving  problems  in 
that  dommn  (16:4).  He  models  the  real-world  entities  required  to  compose  appUcations. 
A  Domain  Engineer  also  determines  how,  if  possible,  to  model  these  entities  within  the 
architectur^ll  constraints  specified  by  a  Software  Engineer  (9).(1,  26) 

3. 2. 1.2  Software  Engineer.  A  Software  Engineer  designs  new  software 
systems  in  an  application  domain  (16:4).  He  is  responsible  for  defining  a  formalized 
structure  (software  architecture)  for  the  domain  knowledge  and  providing  the  translation 
from  the  domzdn-specific  terms  to  executable  software  (9).  (1,  26) 

3. 2. 1.3  Application  Specialist.  An  Application  Specialist  uses  the  domain 
cind  architectural  models  developed  for  a  domain  by  the  Softwzure  and  Domain  Engineers 
(16:4).  He  is  a  sophisticated  “user”  familiar  with  the  overall  domjun.  An  Application 
Specialist  imderstands  what  new  applications  must  do  to  meet  the  requirements  for  a  new 
system.  He  provides  the  application-specific  information  needed  to  specify  and  compose  a 
new  application.  (1,  26) 

3. 2.1. 4  Data  Administrator.  A  Data  Administrator  possesses  detailed 
knowledge  about  the  context  within  which  the  data  in  the  technology  base  is  used.  He  is 
responsible  for  ensiuring  the  data  stored  in  the  technology  base  is  current,  acciurate,  and 
useful  with  respect  to  the  needs  of  the  users. 

3.2.2  Key  Components  of  Architect. 

3.2.2. 1  Software  Architecture.  The  software  architecture  Reindour  and 
Anderson  chose  to  use  for  Architect  was  the  Software  Engineering  Institute’s  (SEI)  Object- 
Connection-Update  (OCU)  model  (19).  The  basic  premise  of  the  OCU  model  is  that 
real-world  systems  can  be  partitioned  into  a  set  of  communicating  subsystems.  In  the 
OCU  model,  subsystems  consist  of  a  controller,  a  set  of  primitive  objects,  an  import  area, 
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and  an  export  area  (19:17).  Figure  3.3  shows  a  graphical  representation  of  this  relationship 
and  is  described  below. 

1.  Controller  -  The  Controller,  as  its  neune  and  position  in  Figinre  3.3  both  imply,  is  a 
critical  element  eiround  which  we  build  every  subsystem.  It  encapsulates  the  mission 
of  the  subsystem  eind  m^lnages  the  connections  between  itself  and  a  set  of  objects 
used  to  perform  that  mission. 

2.  Objects  -  An  Object  is  m  abstraction  of  a  real-world  entity,  and  maintains  state  to 
model  behavior  of  that  real-world  entity. 

3.  Import  Area  -  The  Import  Area  is  the  focal  point  for  the  controller  to  get  access  to 
extemcil  data.  The  Import  Area  obtmns  this  data  from  the  Export  Area  of  other 
subsystems. 

4.  Export  Area  -  The  Export  Area  is  the  focal  point  for  making  internal  data  available 
to  other  subsystems  in  an  application. 

Figure  3.4  shows  the  procedural  interface  for  both  controllers  and  objects,  and  we  describe 
these  interfaces  below. 
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Figure  3.4  OCU  Object  and  Controller  Procedural  Interfaces  (19:18,20) 

•  Controller  (19:19): 

1.  Update  -  The  controller  obtains  state  data  from  the  import  area,  calls  the 
update  functions  of  its  lower-level  primitive  objects  and  subsystems  in  some 
predefined  order,  aind  provides  new  state  data  to  its  export  area. 

2.  Stabilize  -  Puts  the  system  in  a  ready-to-operate  state  consistent  with  the 
ciurent  scenaurio. 

3.  Initialize  -  Creates  the  objects  and  maJtes  the  connections  for  a  subsystem. 

4.  Configure  -  Sets  up  connections  between  the  import  aind  export  areas  and  their 
corresponding  input  amd  output  data. 

5.  Destroy  -  Deaillocates  a  subsystem’s  resources. 

•  Object  (19:20): 

1.  Update  -  Cadculates  the  new  state  and  outputs  of  the  object  based  on  input 
data  amd  the  current  state  of  the  object. 

2.  Create  -  Allocates  the  resources  necessauy  to  create  a  new  instamce  of  am  object. 

3.  SetFunction  -  Modifies  the  way  am  object  cadculates  its  state  data. 
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4.  SetState  -  Bypasses  the  objects  update  function  to  set  the  state  of  an  object 
directly. 

5.  Destroy  -  Deallocates  the  resources  held  by  an  object. 

The  types  of  data  an  object  deals  with  are  (19:20,21): 

1.  Input  Data  -  Data  used  by  an  object  to  calculate  its  new  state.  Other  subsystems 
or  objects  from  within  the  same  subsystem  can  import  this  data.  The  source  of  the 
data  is  transparent  to  the  object. 

2.  Output  Data  -  The  extem2dly  visible  state  of  an  object  made  available  by  the  most 
recent  update.  This  state  data  cein  be  exported  to  other  subsystems  or  provided 
to  other  objects  within  the  same  subsystem.  The  destination  of  the  output  data  is 
transparent  to  the  object. 

3.  Attributes  -  Describe  important  characteristics  of  an  object. 

4.  CurrentState  -  Data  that,  taken  together,  defines  the  current  condition  of  an  object. 
Not  all  of  this  data  needs  to  be  externally  visible. 

5.  CoeflSicients  -  A  special  type  of  attribute  used  in  update  algorithms  to  calculate 
an  object’s  state.  Changes  in  coefficient  values  modify  the  behavior  of  an  object’s 
update  procedure. 

6.  Constants  -  Also  a  special  type  of  attribute.  It  cannot,  however,  be  modified  to 
change  an  object’s  behavior. 

This  brief  discussion  of  the  OCU  softweure  architectural  model  provides  the  groimd- 
work  for  our  discussion  of  design  and  implementation  decisions,  as  well  as  our  development 
of  an  object  model  for  the  OCU  architectmre  in  the  next  chapter.  The  SEI  “Model-Based 
Software  Development”  article  (19)  is  a  good  source  of  additional  information  on  the 
“vanilla”  OCU  model,  while  several  AFIT  theses  (1,  26,  35)  provide  more  insight  into 
the  original  AFIT  implementation  of  the  OCU  model  as  the  software  architecture  for 
Architect. 


3. 2. 2. 2  Domain.  For  an  application  dom2un  to  be  used  in  an  application 
composition  system,  the  Domain  and  Software  Engineers  must  first  capture  knowledge 


3-8 


about  the  domain  in  an  object  model.  Randour  and  Anderson  used  the  Logic  Circuits 
domain  to  vsdidate  Architect  by  composing  and  executing  domain-oriented  application 
specifications.  We  discuss  the  Logic  Circuits  domzun  further  in  Section  4.2,  when  we 
develop  an  object  model  for  the  domain  using  Rumbaugh’s  Object  Modeling  Technique 
(29).  Randour  and  Anderson’s  theses  (1,  26)  also  cover  it  in  great  detail. 

3. 2.2. 3  Persistent  Technology  Base.  The  Persistent  Technology  Base  of 
Architect  is  file-based.  Artifacts  created  in  the  Working  Technology  Base  are  stored  in 
separate  files  in  a  format  that  adheres  to  domain-specific  and  architecture  grammars  (26:4- 
7).  This  way,  saved  artifacts  can  be  parsed  back  in  to  the  Working  Technology  Base  using 
the  Refine  parse-file  function.  The  capabihty  to  parse  saved  files  back  in  to  the  Working 
Technology  Base  allows  objects  saved  in  the  Persistent  Technology  Base  to  be  reloaded. 
Randour  describes  the  directory  structure  Jind  naming  conventions  required  by  Architect 
in  her  thesis  (26:Appendix  A,  section  5). 

In  addition  to  the  application-specific  artifacts  composed  by  Application  Specialists 
that  are  stored  in  the  Persistent  Technology  Base,  it  also  contains  the  OCU  architectiure 
model,  all  domain-specific  models,  and  all  the  programs  needed  to  make  Architect  execute. 
All  of  these  files  must  be  loaded  into  the  Working  Technology  Base  before  the  system  can 
be  used.  Again,  Architect  softw2u:e  requires  a  pre-specified  directory  structure  Jind  naming 
conventions;  these  requirements  are  also  found  in  Randour’s  thesis  (26;Appendix  A,  section 
5). 


S.2.2.4  Software  Refinery.  Architect  was  implemented  using  Soft¬ 
ware  RefinerV^^,  a  formal-based  specification  emd  programming  environment.  The 
Software  Refinery  environment  includes  a  wide-spectrum  programming  language  (RE¬ 
FINE)  that  supports  set  theory,  logic,  transformation  rules,  pattern  matching,  smd  proce¬ 
dures  (27:1-2).  Architect’s  Working  Technology  Base  was  implemented  using  SOFTWARE 
Refinery’s  object  base,  while  Dialect,  Software  Refinery’s  language  definition  facil¬ 
ity,  was  used  to  define  Architect’s  Domain  Specific  and  Architecture  grammars.  DIALECT 
is  also  used  to  parse  compatible  text  files  into  the  SOFTWARE  Refinery  object  base  and 
to  write  object  specifications  out  to  file.  Finally,  Intervista  provides  Architect’s  window- 
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based  graphical  user  interface.  The  SOFTWARE  REFINERY  environment  was  selected  as  the 
development  environment  for  Architect  because  its  powerful  integrated  tool  set  supports 
rapid  prototyping  so  well  (26:3-23). 

3. 2. 3  Functionality  of  Architect.  This  section  describes  the  processes  of  capturing 
new  domriin  knowledge  and  composing  systems  under  Architect,  using  the  visual  interface 
developed  by  Weide  (35). 

3.2.3. 1  Capturing  New  Domains.  To  capture  new  domains,  the  Domain 
Enginee*  <uid  Software  Engineer  need  to  develop  SOFTWARE  REFINERY  source  code  files. 
A  separate  file  is  created  for  each  primitive  in  the  domain,  for  the  overall  object  model, 
and  for  a  domain-specific  grammar.  Also,  the  Software  Engineer  needs  to  create  a  file 
describing  the  visual  information  for  the  domain  primitives.  This  file  is  written  in  a  visual 
specification  language  that  can  be  parsed  in  using  a  visual  description  grammar  (35). 
Once  these  files  eire  created,  compiled,  and  verified,  they  are  placed  in  the  technology  base 
directory  structure. 

3. 2. 3. 2  Composing  Systems.  To  start  an  Architect  session,  the  Application 
Specialist  starts  a  REFINE  session  in  the  root  of  the  directory  structxire  referred  to  in  sec¬ 
tion  3.2.2.3.  By  loading  a  startup  file  at  the  lisp  prompt,  the  entire  Architect  environment 
is  loaded.  This  includes  loading  DIALECT,  Intervista,  and  zdl  the  executable  Architect 
code,  as  well  as  the  OCU  zuchitecture  model  and  all  domain-specific  models,  grammars, 
and  visual  descriptions.  The  user  is  then  presented  with  a  window-based  menu  system, 
and  the  session  begins.  At  this  point,  the  Application  Specialist  cem  load  in  previously 
saved  application  compositions,  or  begin  new  ones.  Once  a  session  contains  an  application 
composition  that  has  been  created  and/or  modified,  the  Application  Specialist  csin  save  it 
to  the  technology  base  through  a  menu  option. 

3.3  Requirements  Analysis  Results 

This  section  provides  the  results  of  our  requirements  analysis  for  improving  Architect 
by  moving  towzurds  a  domain-oriented  application  composition  environment  similar  to  the 
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one  shown  in  Figure  3.1.  Our  implementation  addresses  the  following  list  of  identified 
requirements: 

1.  Identify  Artifacts: 

The  purpose  here  is  to  establish  what  the  data  requirements  are  for  the  technology 
base.  We  began  by  analyzing  the  current  implementation  of  Architect  to  identify 
implementation-specific  requirements,  as  well  as  requirements  for  domain-oriented 
application  composition  systems  in  general. 

2.  Select  OODBMS  for  Technology  Base  Implementation: 

On  the  basis  of  the  data  requirements  we  identified,  and  our  analysis  of  how  the 
data  will  be  used,  we  needed  to  select  the  best  of  the  available  OODBMSs  for 
our  implementation.  We  needed  to  determine  which  of  the  OODBMS  capabilities 
identified  in  our  literature  search  are  important  for  this  application  area,  and  evaluate 
each  of  the  three  systems  available  to  us  based  on  these  criteria. 

3.  Investigate  Database  Communications  Interface: 

We  needed  to  identify  and  ev2duate  options  for  the  communications  backplane  that 
would  allow  other  tools  in  the  new  environment  to  communicate  with  the  OODBMS 
technology  base. 

4.  Provide  a  Central  Repository  for  Software  Artifacts: 

One  of  the  major  goals  of  this  research  was  to  replace  the  file-based  technology 
base  of  Architect  with  an  object-oriented  database  implementation.  This  helps 
to  bridge  the  gap  between  the  current  capabilities  of  Architect,  and  some  of  the 
other  J-MASS  requirements  such  as  the  CONFIGURE  SIMULATION  and  EXECUTE 
Simulation  functionality. 

(a)  Develop  Object  Model  for  Software  Architecture: 

Because  we  are  building  up  an  environment  that  may  have  more  than  one 
composition  system  implementation,  possibly  based  on  the  same  software  archi¬ 
tecture,  we  reqmred  an  implementation-independent  object  model  for  software 


3-11 


architectiires.  The  goal  here  was  to  produce  a  database  schema  definition  of  the 
OCU  model  that  is  not  Architect  dependent. 

(b)  Develop  Object  Model  for  Application  Domains: 

Since  application  domains  are  abo  artifacts  that  may  be  reused  by  multiple  com¬ 
position  systems,  possibly  based  on  different  architectures,  we  had  to  develop 
a  schema  that  describes  the  general  domain  knowledge.  This  general  domain 
schema  can  then  be  extended  for  combinations  of  software  architectures  and 
specific  implementations  using  the  multiple  inheritance  feature  of  OODBMSs. 

(c)  Add  Database  Storage  and  Retrieval  Functionality  to  Architect: 

The  current  functionality  of  Architect  must  be  extended  to  communicate  with 
the  database  for  storage  and  retrieval  of  composed  artifacts.  This  should  be  done 
in  a  incremental  development  process  to  build  up  and  verify  these  capabilities. 

(d)  Provide  for  Storage  of  Miscellaneous  Software  Artifacts: 

Besides  storing  artifacts  produced  by  Architect,  we  fotmd  we  could  also  store 
artifacts  used  for  developing  Architect,  and  other  composition  systems.  We 
identified  what  these  artifacts  were  (source  code,  compiled  code,  visual  interface 
objects,  etc.),  and  provided  the  schema  and  methods  for  their  storage  and 
retrieval. 

5.  Isolate  Domain  Definition  from  Implementation: 

We  found  during  our  requirements  analysis  that  a  database  implementation  put  new 
responsibilities  on  the  Domain  Engineer.  Now,  not  only  did  the  domain  need  to  be 
defined  in  the  object  base  of  the  application  :is  before,  but  the  same  information 
must  be  conununicated  to  a  database  administrator  to  define  the  database  schema 
for  storing  artifacts  of  the  domain.  If  we  could  capture  this  domain  knowledge  in 
the  database  in  the  form  of  a  model  description,  perhaps  we  could  automate  some  of 
these  functions  for  the  Domain  Engineer. 

(a)  Develop  Meta-Model  for  Capturing  Domain  Knowledge: 

Develop  a  meta-model  to  formally  capture  domain  model  definitions  that  could 
be  used  by  automated  transformation  processes. 
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(b)  Provide  Capability  to  Populate  Database  With  Domain  Definitions: 

Provide  the  Domain  Engineer  with  the  capability  to  input  and  modify  domain 
definitions  after  completing  his  domain  analysis.  This  can  be  a  prototype  used  in 
later  research  for  the  Technology  Base  Extender  shown  in  the  upper-left  comer 
of  Figture  3.1. 

(c)  Automate  Transformations  of  Domain  Model  to  Database  Schema: 

Using  rapid  prototyping,  incrementally  develop  an  automated  process  to  trans¬ 
form  the  abstract  domain  definition  into  a  database  schema  for  specific  software 
architectures. 

(d)  Automate  Transformations  of  Domain  Model  to  Object  Base  Definition: 

Using  rapid  prototyping,  incrementally  develop  an  automated  process  for  trans¬ 
forming  the  abstract  domain  definition  into  source  code  necessary  to  describe 
the  domain  in  a  specific  application  object-base  environment. 

6.  Support  Concurrent  Research  Efforts: 

As  the  Architect  system  evolves  with  the  results  of  other  research  at  AFIT,  make  sure 
that  our  extensions  support  the  new  chamges.  Also,  maintain  close  coordination  with 
researchers  to  identify  smy  new  databeise  capabilities  or  benefits  that  would  enhance 
their  research. 

3.4  OODBMS  Comparison 

This  section  discusses  our  selection  of  an  OODBMS.  There  were  three  OODBMSs 
available  to  us:  Matisse,  ObjectStorb,  and  Itasca.  The  designers  of  all  three  systems 
designed  their  products  from  the  ground  up  to  store  objects,  and  to  support  multiple 
inheritemce.  After  highlighting  the  features,  capabilities,  and  differences  of  the  three 
systems,  we  discuss  the  choice  we  made,  and  the  reasons  for  meddng  the  choice. 

3.4-1  Matisse.  The  Matisse  OODBMS  operates  imder  the  client-server  archi¬ 
tecture.  The  Matisse  server  is  a  general  purpose  object  manager,  operating  as  a  multi¬ 
threaded  back-end  server,  that  manages  a  repository  of  persistent  objects  (the  database). 
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and  communicates  with  clients  through  a  remote-procedure-call  (RPC)  interface  (15). 
Matisse  supports  multiple  inheritance,  versioning,  on-line  dynamic  schema  evolution, 
and  ensured  referential  integration  (13).  MATISSE,  using  intrinsic  versioning,  makes  a  new 
version  of  an  object  with  every  change. 

Matisse,  developed  using  C-H-i-,  easily  interfaces  to  C  or  C-t-+.  The  Matisse 
semantic  data  model  is  language  independent;  the  application  programmer  interface  (API) 
uses  the  C  language.  The  API  is  strictly  a  functional  interface,  with  no  extensions  to  the 
C  language;  as  such,  any  programming  language  that  supports  external  calls  can  interface 
with  Matisse.  Since  schema  objects  are  created  in  the  database  through  a  functional 
interface,  they  can  be  modified  or  deleted  at  nm-time,  allowing  a  great  deal  of  on-line 
schema  modification. 

Matisse  is  an  active  database,  supporting  the  execution  of  methods  within  the 
database  environment.  The  database,  however,  does  not  store  the  methods.  The  methods 
are  part  of  the  application  program.  This  means  that  changes  to  the  methods  require 
re-compilation  of  the  C  source  code. 

Matisse  support  tools  include  a  query  language,  a  4GL  capability,  a  schema  editor, 
and  an  object  editor.  Developers  and  end-users  can  use  the  object  editor  to  view  any 
object  in  the  database  using  a  standard  form  or  an  object  window  (14). 

3.4.2  ObjectStore.  The  ObjectStore  OODBMS  also  operates  imder  the 
client-server  architecture.  It  is  an  example  of  an  OODBMS  built  by  extending  an  object- 
oriented  programming  language  to  include  database  functionality.  Written  in  C/C-f-l-,  its 
data  manipulation  and  management  language  (DMML)  is  an  extended  C-l-l-  environment 
that  includes  both  C  and  C-b-l-  library  interfaces  (13). 

Extensions  to  the  language  allow  the  programmer  to  treat  persistent  data  and  tran¬ 
sient  data  the  same.  Persistence  is  not  part  of  the  type  of  an  object  (i.e.,  there  is  no  need 
to  inherit  from  a  special  “persistent  object”  base  class),  therefore  different  instances  of  the 
same  cl2iss  may  be  persistent  or  transient  within  the  same  program  (18).  The  language 
extensions  require  a  pre-compiler  that  converts  extended  language  statements  to  standard 
C  statements. 
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ObjeCtStore  provides  limited  support  for  composite  objects  wd  schema  evolution. 
Since  the  C  source  code  contains  the  schema  definitions,  schema  modifications  require 
re-compilation.  There  is  a  customized  query  language  but  no  4GL  capability. 

ObJECTStore  is  a  static  database;  any  request  results  in  the  database  assembling 
the  object  and  then  peissing  it  to  the  application.  The  most  common  use  of  ObjectStore 
is  in  providing  persistent  data  to  C/C-t-i-  applications. 

S.4‘S  Itasca.  Like  the  other  two  OODBMSs,  Itasca  runs  under  the  client-server 
computing  architecture.  Although  written  with  a  combination  of  C  and  Lisp,  the  Itasca 
DMML  is  essentially  an  interpreted  Lisp  environment  (13).  Like  Matisse,  ItasCA  is  an 
active  database  allowing  methods  to  be  executed  within  the  database.  In  addition,  Itasca 
can  store  the  methods  in  the  database  with  the  objects. 

Language  interfaces  for  Itasca  include  C,  C-i-+,  Lisp,  Common  Lisp  Object  System 
(CLOS),  and,  imder  development,  Ada  (13).  Programming  languages  can  easily  use  objects 
created  by  any  other  language  (13).  The  database  stores  methods  with  the  schema,  in 
interpreted  Lisp  form;  thus,  method  modifications  do  not  require  re-compilation.  Itasca 
also  supports  extensive  schema  modification  without  shutting  the  database  down. 

Itasca  supports  both  shared  and  private  databases  in  a  fully  distributed  database 
environment  with  complete  location  transparency.  Extensive  object  versioning,  passive 
and  eictive  chsmge  notification,  and  elaborate  locking  on  the  object  model  are  a  few  of 
Itasca’s  strengths. 

Itasca  comes  with  three  OSF/Motif  based  productivity  tools:  a  database  adminis¬ 
tration  tool,  a  dynamic  schema  editor,  and  an  active  data  editor.  The  database  admin¬ 
istration  tool  provides  capabilities  for  site  maintenance  including  backups,  addition  and 
modification  of  user  security,  and  system  performance  monitoring.  The  dynamic  schema 
editor  provides  a  simple  mechanism  for  modifying  class  definitions,  to  include  attributes 
and  methods.  The  active  data  editor  allows  views  and  modifications  of  objects  in  the 
database,  and  provides  a  desktop  work  area  for  query  storage. 
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S.4-4  Selection  of  an  OODBMS.  We  chose  the  ITASCA  OODBMS  for  our 
implementation.  We  felt  the  dynamic  schema  evolution  feature  without  re-compilation 
of  methods  best  met  our  need  for  a  rapid  prototyping  capability.  The  application  we  were 
extending  with  database  functionality  runs  under  Software  Refinery,  a  product  that 
runs  in  the  Allegro  Common  Lisp  environment.  Since  ITASCA  also  runs  in  a  Common  Lisp 
environment,  we  did  not  have  to  translate  to  a  target  language.  The  storage  of  methods 
in  the  database  and  support  for  a  number  of  languages  accessing  the  same  objects  will 
support  reuse,  an  important  requirement  in  an  evolving  prototype  system. 

Itasca  provided  a  remote  Lisp  interface  for  its  Lisp  API  that  supported  both  Allegro 
Common  Lisp  and  Lucid  Common  Lisp.  The  remote  Lisp  interface,  as  delivered,  supported 
Allegro  versions  after  4.0.  Since  AFIT’s  current  version  of  Software  REFINERY  runs  on 
Allegro  version  3.1.13,  we  had  to  make  a  few  modifications  to  the  source  code  to  make  it 
backward  compatible.  The  modifications  were  syntactic  in  nature,  and  were  provided  by 
Allegro  technical  support  personnel.  SOFTWARE  REFINERY  has  scheduled  a  new  release  of 
Refine  that  will  operate  under  version  4.1  of  Allegro  Common  Lisp.  This  may  make  the 
use  of  Itasca  even  more  valuable,  as  the  CLOS  interface  may  allow  persistence  of  objects 
in  the  databeise,  making  persistence  transparent  to  application  programs. 

3.5  Conclusion 

We  began  this  chapter  by  2injdyzing  and  explaining  how  the  current  implementation 
of  Architect  operates  in  a  stand-alone  mode.  This  provides  the  reader  with  a  good 
reference  point  for  the  state  of  the  system  before  our  euldition  of  an  OODBMS  technology 
base.  Then,  based  on  the  results  of  our  literature  search  smd  analysis  of  Architect, 
we  identified  the  requirements  and  goals  we  developed  for  creating  a  domain-oriented 
application  composition  environment  in  which  Architect  could  work.  A  description  of 
this  new  environment  is  provided  later  in  this  dociunent  when  we  present  our  results 
and  conclusions.  We  compared  Matisse,  ObjectStore,  and  ITASCA  OODBMSs,  and 
discussed  our  rationale  for  using  Itasca  for  our  technology  base.  Having  identified  our 
requirements,  we  begin  our  design  and  implementation. 
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IV.  Design  and  Implementation  of  an  OODBMS  Technology  Base 

4.1  Introduction 

This  chapter  describes  the  steps  we  took  to  design  and  implement  an  OODBMS 
technology  bjise  for  Architect.  Section  4.2  discusses  our  selection  of  a  validating  domain 
with  which  to  test  our  system.  In  that  section,  we  identify  the  types  of  artifacts  we  want 
to  store  in  the  technology  base,  develop  an  object  model  for  the  domain,  and  develop 
storage  and  retrieval  tests  to  execute  against  the  finished  product.  Section  4.3  discusses 
our  investigation  and  selection  of  a  communications  method  between  the  database  and 
application  programs.  Section  4.4  covers  the  development  of  an  object  model  for  the 
software  architecture  and  its  subsequent  conversion  to  a  database  schema.  Section  4.5 
covers  the  process  we  went  through  to  incorporate  the  OODBMS  version  of  the  technology 
base  into  AVSI.  Finally,  we  discuss  the  development  of  the  meta-model  used  by  a  Domain 
Engineer  to  generate  the  domain-specific  portion  of  the  database  schema  and  the  formal 
domain  definition  for  the  application  composer. 

4.2  Selection  of  a  Validating  Domain 

One  of  the  decisions  we  had  to  make  was  what  application  domain  to  use  to  test 
our  OODBMS  implementation  of  the  technology  bs«e.  One  factor  we  considered  in  that 
decision  was  our  desire  to  transition  from  the  file-based  technology  base  to  an  OODBMS 
implementation  without  losing  domain  analysis  work  done  by  previous  researchers.  Trans¬ 
forming  am  existing  technology  baise  of  software  airtifamts  haid  the  added  benefit  of  providing 
us  with  the  test  data  against  which  to  check  our  new  implementation.  Appendix  A  contauns 
a  description  of  the  technology  base  of  primitive  objects  for  the  logic  circuits  domain. 
Appendix  C  contauns  applications  built  from  the  primitives.  These  softwaure  autifacts  were 
part  of  the  baseline  system  we  inherited  at  the  staut  of  our  reseaurch.  Since  other  researchers 
were  ailreaidy  extending  the  technology  base  to  other  domains,  we  saw  little  benefit  in 
developing  a  new  domaiin  with  which  to  test  om:  implementation  of  the  technology  base. 
For  these  reaisons,  we  decided  to  use  the  existing  logic  circuits  domaun  as  our  vaJidating 
domaun. 
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The  domain  itself  was  not  the  focus  of  this  research.  We  refer  the  reader  interested 
in  the  logic  circuits  domain,  and  the  analysis  of  that  domain,  to  (1)  and  (22);  these  two 
sources  provided  us  with  enough  knowledge  of  the  domain  to  conduct  our  research. 


4.2.1  Identification  of  Artifacts  in  Selected  Domain.  The  software  artifacts 
residing  in  the  baseline  technology  base  were  of  two  types:  primitives  and  applications. 

•  PRIMITIVES 

-  AND-GATE 

-  OR-GATE 

-  NAND-GATE 

-  NOR-GATE 

-  NOT-GATE 

-  SWITCH 

-  LED 

-  COUNTER 

-  DECODER 

-  4-INPUT  MULTIPLEXER  (MUX) 

-  JK-FLOP-FLOP 

-  HALF-ADDER 

The  following  is  a  brief  description  of  the  composed  applications  (refer  to  Appendix  C 
for  more  information). 

•  APPLICATIONS 

-  TEST 

This  is  a  simple  test  application  that  uses  2  switches,  2  “and”  gates,  and  2 
LEDs. 

-  ADDER 

This  application  is  a  full  adder.  It  is  built  using  2  subsystems  that  are  half 
adders,  built  out  of  “and”,  “or”,  and  “not”  gates. 

-  DECODER 

This  application  provides  a  test  of  a  “decoder”  primitive  by  providing  3  input 
switches  and  8  output  LEDs. 

-  ADD-AND-DECODEl 

This  application  tests  the  combination  of  an  adder  emd  a  decoder.  The  adder 
is  a  subsystem  composed  of  2  half-adder  subsystems,  each  composed  of  “and” 
gates,  “or”  gates,  and  “not”  gates.  The  decoder  is  also  a  subsystem,  composed 
of  “and”  gates  and  “not”  gates. 
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-  ADD-AND-DECODE2 

This  application  is  similar  to  the  ADD-AND-DECODEl  application  mentioned 
above,  except  the  decoder  subsystem  is  implemented  as  a  decoder  with  out¬ 
put  (i.e.,  the  LEDs  have  been  moved  down  under  the  control  of  the  decoder 
subsystem). 

-  BCD-ADDER 

This  application  tests  a  subsystem  implementation  of  a  BCD-adder  using  prim¬ 
itive  gates  and  half-adders. 

-  BINARY-ARRAY-MULTIPLIERl 

This  application  implements  a  binary  array  multiplier  as  a  top  level  subsys¬ 
tem,  composed  of  “wd”  gates,  “not”  gates,  switches,  leds,  and  2  half-adder 
subsystems,  each  of  which  is  composed  of  “and”  gates,  “or”  gates,  and  “not” 
gates. 

-  BINARY-ARRAY-MULTIPLIER2 

This  application  implements  a  binary  array  multiplier  similar  to  BINARY- 
ARRAY-MULTIPLIERl  listed  above,  except  that  primitive  half-adders  are  used 
instead  of  lower-level  subsystems  composed  of  primitive  gates. 

-  THREE-TO-EIGHT-DECODER 

This  application  composes  “and”  gates  and  “not”  gates  into  a  subsystem  im¬ 
plementation  of  a  3-to-8  decoder. 


Development  of  Object  Model  for  Selected  Domain.  Because  the  object 
model  of  a  dommn  plays  such  a  critical  role  in  our  development  of  a  database  schema 
eind  the  object  hierarchy  in  the  object  base,  our  next  step  was  to  use  Rumbaugh’s  object 
modeling  technique  (29)  to  produce  an  object  model  of  the  logic  circuits  domain.  Figure  4.1 
is  the  object  model  we  developed  by  analyzing  the  artifacts  in  the  baseline  technology  base 
and  referring  to  our  two  primary  sources  of  domain  knowledge  (1,  22)  discussed  earlier. 

The  Architecture  Primitive  at  the  top  of  Figure  4.1  is  not  truly  a  part  of  the  logic 
circuits  domain,  but  is  actujdly  a  class  foimd  in  the  software  architecture  model  of  the 
application-composition  system.  This  association  points  out  that  the  logic  circuits  domain 
model  inherits  from  the  architecture  object  model  to  produce  a  complete  object  model  of 
a  dommn  that  conforms  to  the  structure  of  a  specific  architecture.  Please  note  too,  the 
legend  in  the  lower  left  hand  comer  of  Figure  4.1.  A  clear  box  represents  a  concrete  class 
and  a  shaded  box  represents  an  abstract  class.  An  abstract  class  is  never  instantiated;  it 
merely  provides  a  high-level  definition  that  one  or  more  subclasses  can  expand  upon.  A 
concrete  class  inherits  attributes  and  operations  from  parent  abstract  classes,  and  can  be 
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Figure  4.1  Object  Model  of  Logic  Circuits  Domain 


instantiated  to  create  objects  of  that  class.  As  an  example,  it  makes  no  sense  in  the  logic 
circuits  domain  to  create  a  GATE  object  vmless  you  further  defined  it  as  sm  AND-GATE, 
OR-GATE,  NAND-GATE,  NOR-GATE,  or  NOT-GATE  object.  On  the  other  hand,  when 
an  AND-GATE  object  is  instantiated,  it  inherits  attributes  Delay,  Mil-Spec?,  and  Power- 
level  from  abstract  class  GATE,  as  well  as  the  attribute  Manufacturer  from  abstract  class 
CIRCUIT-ARTIFACT. 

Discussing  Figure  4.1  from  top  to  bottom  and  left  to  right,  the  first  cleiss  we  come 
across  in  the  logic  circuits  domain  (discoimting  Architecture  Primitive)  is  the  abstract 
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class  labeled  Circmts.  This  is  a  container  class  we  require  in  our  implementation  to  aid  in 
extracting  a  list  of  available  domains  from  a  technology  base  full  of  domains.  We  require 
that  it  have  no  attributes  or  operations  associated  with  it.  Its  sole  purpose  is  to  provide 
a  h2mdle  by  which  to  access  a  domain.  In  Section  4.6  we  explain  the  reasons  for  this 
implementation  decision  when  we  discuss  the  object  model  for  defining  domains. 

The  next  object  class  in  Figure  4.1  is  the  CIRCUIT-ARTIFACT  cleiss.  CIRCUIT- 
ARTIFACT  has  one  attribute,  Manufactmer,  which  all  other  object  classes  in  the  object 
model  inherit.  We  feel  it  is  important  to  note  at  this  point  that  this  is  how  we  chose  to 
model  this  domain,  and  that  other  solutions  can  provide  the  S2une  results.  Figure  4.2  for 
exeimple,  is  the  same  object  model  with  the  abstract  class  CIRCUIT- ARTIFACT  removed. 
To  propagate  the  Manufacturer  attribute  to  all  object  classes  in  the  domaun,  we  had  to 
replicate  it  in  the  GATE,  SWITCH,  LED,  and  COMPONENT  classes.  We  chose  to  take  full 
advantage  of  inheritance  and  add  the  CIRCUIT- ARTIFACT  class  with  the  Mamufacturer 
attribute.  Referring  again  to  Figure  4.1,  we  see  that  a  CIRCUIT-ARTIFACT  is  further 
defined  as  a  GATE,  SWITCH,  LED,  or  COMPONENT.  An  AND-GATE,  OR-GATE, 
NAND-GATE,  NOR-GATE,  or  NOT-GATE  is  a  more  detailed  definition  of  a  GATE, 
while  a  COUNTER,  MUX,  HALF-ADDER,  DECODER,  or  JK-FLIP-FLOP  is  refined 
from  a  COMPONENT.  There  may  be  mainy  good  ailtematives  to  our  object  model  of  the 
logic  circuits  domaun,  but  the  model  in  Figure  4.1  is  the  one  we  used  in  our  research. 

4-3  Database  Communications  Platform 

Our  goad  wais  to  investigate  current  implementations  of  CORBA-compliant  database 
interfaces.  Unfortunately,  we  found  that  the  Object  Mamagement  Group  haid  put  a  lot  of 
effort  into  developing  a  staindaird  interfawre,  but  ais  yet  there  are  only  a  few  commercial  ap¬ 
plications  addressing  the  standaird.  The  implementation  of  a  CORBA-compliaint  interface 
is  composed  of  a  number  of  pieces  (23),  am  object  request  broker  (ORB)  for  the  database 
aud  am  interfaice  definition  language  (DDL)  being  two  of  the  key  items. 

Although  we  did  not  find  a  CORBA-compliant  interface  to  use,  we  investigated  two 
possibilities  to  build  a  communications  interfaice  on. 
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Figure  4.2  Alternate  Object  Model  of  Logic  Circuits  Domain 


4.3.1  ToolTalk.  The  first  product  we  investigated  was  the  ToolTalk'^**  service, 
from  SunSoft'^'^,  am  inter-application  message  system  designed  to  promote  cooperation 
cimong  independently  developed  applications  across  networks.  The  ToolTalk  service  can 
be  used  in  two  ways  (32): 


•  Applications  use  the  ToolTalk  service  directly,  calling  functions  contained  in  the 
ToolTalk  API  library  to  create,  send,  and  receive  messages. 
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•  Applications  could  use  a  “service”  built  on  top  of  the  ToolTalk  service.  These 

application  services  would  then  use  the  TOOLTalk  service  as  a  communications 

backplane. 

Currently  the  ToolTalk  service  messages  are  file-based,  although  SunSoft  is 
incorporating  it  in  their  Project  DOE,  a  move  toweirds  a  distributed  object  paradigm. 
Services  are  accessed  by  C  library  routines.  In  order  to  use  ToolTalk  for  our  research, 
an  message  interface  would  have  to  be  developed,  in  C,  for  the  application  as  well  as  the 
database. 

As  SunSoft’s  Project  DOE  matures,  the  distributed  object  paradigm  would  possi¬ 
bly  make  ToolTalk  a  good  development  tool  for  a  CORBA-compliant  communications 
backplane.  However,  the  development  of  a  CORBA-compliant  interface  was  beyond  the 
scope  of  this  research  effort. 

4.3.2  Itasca’s  Remote  Lisp  API.  The  release  of  Itasca  at  AFIT  contained 
a  user  support  library  where  we  foimd,  among  other  things,  a  remote  Lisp  application 
programmer  interface  (API).  This  API  supports  the  client/server  model  of  communications 
over  a  network,  £illowing  multiple  application  progrjuns  running  on  various  network  work¬ 
stations  to  communicate  with  the  ITASCA  databeise  server  running  on  a  single  workstation. 
The  API  supported  Lisp  interfaces  to  either  Lucid  Common  Lisp  (the  Lisp  that  ITASCA 
nms  under)  or  AUegro  Common  Lisp.  The  fact  that  SOFTWARE  REFINERY  nms  imder 
Allegro  Lisp  version  3.1.13  made  this  an  attractive  possibility  for  our  implementation.  Two 
of  the  key  features  were  that  commimications  were  already  supported,  and  that  a  common 
language  was  supported  by  ITASCA  and  SOFTWARE  REFINERY. 

Using  our  rapid  prototyping  approach,  we  beg^ul  investigating  and  fzuniliarizing 
ourselves  with  ITASCA  using  the  Allegro  Common  Lisp  software  (version  4.1)  available 
on  our  network  and  the  remote  Lisp  interface  software. 

Otu:  next  phase  was  to  test  the  remote  Lisp  interfew:e  within  the  EMACS  environment 
that  Software  Refinery  runs  imder  (Allegro  version  3.1.13).  We  found  that  the  remote 
API  hzwi  been  written  to  support  Allegro  versions  4.0  2md  greater.  Specifically,  the  interface 
to  stream  sockets  had  changed  eifter  version  4.0  was  released.  We  contacted  both  Itasca 
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and  Allegro  customer  support  centers,  and  received  the  necessary  changes  to  make  the 
software  operate  imder  version  3.1.13  of  Allegro  Common  Lisp. 

Our  last  phase  was  to  integrate  the  remote  Lisp  API  directly  within  the  Refine 
environment.  We  found  that  we  could  easily  transfer  data  back  and  forth  between  a  REFINE 
application  program  and  an  Itasca  server  running  on  another  network  workstation. 

4-3.3  Conclusion.  Based  on  the  success  of  the  ItaSCA  remote  Lisp  interface 
in  dealing  with  REFINE  application  programs,  we  selected  this  option  to  represent  our 
communications  backplane  for  this  first  prototype  version  of  a  domain-oriented  application 
composition  environment. 

4.4  Target  Architecture  Description 

One  of  the  major  goals  in  our  research  was  to  give  Architect  the  ability  to  store 
and  retrieve  artifacts  using  the  database.  Since  Architect  already  had  an  object  model 
developed  for  the  OCU  architecture,  we  could  have  simply  replicated  the  same  object 
model  in  our  database  schema.  After  a  close  analysis  of  the  AVSI  systert .  we  found  its 
developers  designed  the  object  model  with  ease  of  population  and  execution  in  mind.  The 
flattened  tree  structure  of  AVSI,  with  applications,  subsystems,  emd  primitive  objects  at 
the  same  level,  allows  DIALECT  to  easily  parse  artifacts  in  from  and  out  to  text  files. 
There  is,  however,  some  loss  of  the  hierarchy  inherent  to  the  OCU  model.  AVSI’s  method 
of  referencing  object  relationships  through  unique  object  names  within  each  application 
makes  execution  of  applications  easier;  however,  a  database  storing  multiple  applications 
cannot  meiintain  this  unique  n2une  requirement.  Subsystems  and  primitives  from  several 
applications  could  have  the  ssune  names,  and  the  database  requires  names  be  unique 
throughout. 

4-4-1  Object-Connection-Update  (OCU)  Architecture.  Besides  storing  eirtifacts 
for  reuse  by  AVSI,  another  goal  was  to  allow  access  to  the  same  data  by  future  applications. 
With  this  in  mind,  we  decided  to  design  our  own  object  model  for  OCU  that  was  less 
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Software  Refinery  implementation  specific,  and  to  use  this  model  for  building  our 
database  schema. 

Following  Rumbaugh’s  (29)  object  modeling  technique  (OMT),  we  identified  the  key 
objects  of  the  OCU  model,  and  the  associations  between  them.  The  basic  hierarchy  of 
the  OCU  model  is  an  application,  controlling  a  number  of  top-level  subsystems,  each  of 
which  controls  any  niunber  of  primitive  objects  and  lower  level  subsystems.  To  capture 
this  reclusive  nesting  of  subsystems,  we  abstracted  primitive  objects  and  subsystems  under 
a  new  superclass  called  an  element.  Each  subsystem  controls  any  number  of  elements,  any 
of  which  cein  be  another  subsystem  which  in  turn  controls  any  niunber  of  elements,  and  so 
on. 


OCU  Object  Model  Development.  In  the  model  we  developed  (Figure  4.3), 
associations  between  objects  are  maintained  through  the  object  identifiers  generated  by 
the  system,  as  opposed  to  the  value  of  a  name  attribute.  This  eliminates  the  need  for 
uniquely  named  objects,  and  reduces  any  overhead  associated  with  changing  the  value  of 
an  object’s  name. 

In  the  Architect  system,  all  the  inputs  and  outputs  of  the  primitive  objects  controlled 
by  a  subsystem  are  imports  and  exports  of  the  subsystem.  We  felt  this  to  be  an  imple¬ 
mentation  decision  that  the  database  should  not  carry  over,  allowing  future  applications 
greater  flexibility.  In  our  interpretation  of  the  OCU  model,  an  import  of  a  subsystem  is 
cin  externally  available  in  'ut  port  for  the  subsystem,  which  internally  provides  its  value 
to  one  or  more  inputs  of  primitives,  and/or  imports  of  lower  level  subsystems,  that  the 
subsystem  controls.  An  export  of  a  subsystem  is  em  externally  available  output  port  with 
an  internally  controlled  value. 

This  object  model  is  not  complete.  The  definition  of  what  exactly  an  application 
is,  and  how  it  executes,  is  the  subject  of  other  research  currently  under  study  at  AFIT 
(33,  36).  In  our  current  version,  an  application  simply  consists  of  a  top-level  subsystem 
that  executes  in  a  non-event  driven  sequential  manner.  Welgan  (36)  and  Waggoner’s  (33) 
research  expands  application  definitions  to  include  event-driven  sequential  and  time-driven 
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Figure  4.3  Object  Model  of  Object-Connection-Update  (OCU)  Architectxire 

sequential  operating  modes.  The  dynamic  schema  modification  characteristic  of  ITASCA 
will  allow  the  addition  of  future  research  results  with  little  or  no  impact. 

Our  representation  of  the  OCU  ardiitecture  model  is  shown  in  Figure  4.3.  Elements 
of  application  domains  are  defined  as  subclasses  of  our  PRIMITIVE  class.  In  this  way,  the 
two  domain  models  become  one  as  illustrated  in  Figure  4.4. 

4.5  Incorporation  0/ ITASCA  in  AVSI 

With  all  the  pieces  defined,  the  last  step  was  to  incorporate  the  database  functionality 
into  the  AVSI  system.  As  far  as  the  Application  Specialist  is  concerned,  the  database 
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functions  the  same  as  the  file-based  tedmology  base  did.  Our  changes  are  virtually 
transparent.  There  is  no  loss  of  current  AVSI  capability,  but  new  options  are  available 
for  saving  and  retrieving  composed  applications  in  Itasca. 

A  simple  example  of  a  composed  application  is  a  light,  consisting  of  a  switch  and  a 
LED.  This  application,  which  is  used  as  an  example  in  Appendix  E,  will  be  referred  to 
throughout  this  section. 

4.5.1  Background.  The  methodology  for  saving  and  restoring  composed  applica¬ 
tions  relied  heavily  on  the  tree  structures  in  the  object  models  of  both  AVSI  and  ItaSCA. 
Although  there  is  not  a  one-to-one  correspondence  between  the  two  structures,  they  are 
similar  in  the  information  they  contain.  The  problem,  then,  was  to  figure  out  the  mapping 
from  one  to  the  other,  and  vice  versa. 

The  root  of  the  tree  structure  of  an  AVSI  composed  application  is  an  object  of 
type  SPEC-OBJ  (Figure  4.5).  The  AVSI  software  enforces  the  structure  of  this  tree 
through  its  semantic  checks.  Our  assumption  was  that  any  application  the  user  wants 
to  save  to  the  database  has  already  passed  the  AVSI  semantic  checks.  The  second  level 
of  the  tree  structure  contains  one,  and  only  one,  object  of  type  APPLICATION-OBJ. 
A  DESCRIPTOR-OBJ  for  the  application,  a  SUBSYSTEM-OBJ  for  each  OCU  subsys¬ 
tem  in  the  application,  and  one  object  that  is  a  subclass  of  PRIMITIVE-OBJ  for  each 
primitive  object  in  the  application  are  also  on  the  second  level.  The  third  level  of  the 
tree  extends  down  from  the  SUBSYSTEM-OBJ  objects  and  contains  objects  of  type 
IMPORT-OBJ  smd  EXPORT-OBJ  associated  with  each  subsystem;  one  for  each  input 
and  output,  respectively,  of  the  primitive  objects  the  subsystem  controls.  Additionally,  the 
sets  of  objects  that  are  subclasses  of  class  STATEMENT-OBJ  form  the  “Update”  functions 
for  the  APPLICATION-OBJ  and  all  SUBSYSTEM-OBJs.  The  foiuth,  and  final,  level  of 
the  tree  extends  dovm  from  the  IMPORT-OBJ  and  EXPORT-OBJ  objects  and  contains 
objects  of  type  SOURCEJ-OBJ  and  TARGET-OBJ. 

As  noted  before,  the  eurchitectural  structure  of  AVSI  is  not  contained  in  the  tree 
itself,  but  in  unique  neune  references  in  the  objects  themselves.  The  APPLICATION-OBJ 
contciins  a  list  of  the  highest-level  object(s)  of  type  SUBSYSTEM-OBJ  in  the  application  in 
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Figure  4.5  AVSI  Instance  Diagram  for  Light  Application 

its  APPLICATION-COMPONENTS  attribute.  For  our  “Light"  example,  this  consists  of 
the  one  subsystem  named  “THEJ-LIGHT”  (Figure  4.5).  Each  SUBSYSTEM-OBJ  contains 
a  list  of  names  of  the  PRJMITIVEJ-OBJ  objects  and  lower-level  SUBSYSTEM-OBJ  objects 
it  controls  in  its  CONTROLLEES  attribute.  For  our  example,  this  is  the  names  “THEl- 
SWITCH”  and  “THE-LED”  (Figure  4.5).  Each  EXPORT-OBJ  keeps  the  name  of  the 
PRIMITIVE-OBJ  it  belongs  to  in  its  PRODUCER  attribute,  and  each  IMPORT-OBJ 
keeps  the  name  of  the  PRIMITIVE-OBJ  it  belongs  to  in  its  CONSUMER  attribute.  Each 
SOURCE-OBJ  is  associated  with  an  EXPORT-OBJ  somewhere  within  the  application  and 
contains  the  following  three  things. 
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1.  The  name  of  the  EXPORT-OBJ  in  its  SOURCE!*NAME  attribute, 

2.  The  name  of  the  PRIMITIVE-OBJ  that  produces  the  export  value  in  its  SOURCE!' 

OBJECT  attribute,  and 

3.  The  name  of  the  SUBSYSTEM-OBJ  that  controls  the  primitive  object  in  its  SOURCEJ- 

SUBSYSTEM  attribute. 

The  TARGET-OBJ  is  similarly  associated  with  an  IMPORT-OBJ  somewhere  within  the 
application  and  contains  the  following  three  things. 

1.  The  name  of  the  IMPORT-OBJ  in  its  TARGET-NAME  attribute, 

2.  The  name  of  the  PRIMITIVEl-OBJ  that  consumes  the  import  value  in  its  TARGET- 

OBJECT  attribute,  and 

3.  The  name  of  the  SUBSYSTEM-OBJ  that  controls  the  primitive  object  in  its  TARGET- 

SUBSYSTEM  attribute(Figure  4.5). 

Because  Itasca  uses  a  single  name  space  for  class  names,  we  prepended  the  string 
“OCU-”  to  class  names  derived  from  Figure  4.3.  This  eliminates  future  collisions  when 
other  architectures  might  be  explored.  The  root  of  the  tree  structure  for  a  saved  application 
in  Itasca  is  an  OCU- APPLICATION  object  (Figure  4.6).  Its  leaves  are  the  set  of  top- 
level  OCU-SUBSYSTEM  objects  contained  in  the  application.  Each  OCU-SUBSYSTEM 
object  contains  leaves  of  lower-level  SUBSYSTEM-OBJ  objects  and  instances  of  OCU- 
PRIMITIVE  subclasses  (inherited  in  the  domain-specific  object  model)  that  it  controls. 

In  turn,  each  instance  of  an  OCU-PRIMITIVE  subclass  contains  leaves  for  its  inputs 
jmd  outputs,  contained  in  instances  of  OCU-INPUT  and  OCU-OUTPUT  respectively. 
Contzuned  in  each  OCU-INPUT  object  is  a  referential  attribute  that  identifies  its  source 
OCU-OUTPUT(s).  Note,  also,  that  all  references  between  objects  in  this  structure  cire 
based  on  the  iTASCA-generated  object  identifiers,  and  do  not  rely  on  the  names  of  the 
objects  themselves. 

Each  element  in  the  OCU  model  (applications,  subsystems,  and  primitive  objects) 
has  an  associated  update  function.  The  Domain  Engineer  defines  the  update  functions  for 
primitive  objects,  and  these  do  not  change  during  a  session  of  AVSI;  they  become  a  part  of 
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Figure  4.6  ITASCA  Instance  Diagram  for  Light  Application 


the  domain-specific  object  model  stored  in  the  technology  base.  When  saving  applications 
to  the  database,  primitive  objects  store  only  the  name  of  their  update  function.  The  other 
update  functions  (applications  and  subsystems)  are  composed  within  the  AVSI  session, 
and  hence  need  to  be  saved.  We  store  these  functions  as  an  ordered  sequence  of  OCU- 
STATEMENT  objects  in  the  UPDATE-FUNCTION  attribute  of  OCU-APPLICATION 
and  OCU-SUBSYSTEM  objects  (Figure  4.6). 


4.5.2  Saving  Composed  Applications  into  ITASCA.  To  save  an  application  com¬ 
posed  with  AVSI  to  the  database,  we  first  walk  the  AVSI  tree  structure  in  a  top  down 
fashion.  We  create  a  corresponding  OCU-APPLICATION  object  in  the  database  for 
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the  APPLICATION-OBJ,  and  keep  its  object  identifier  as  a  reference  to  the  root  of  the 
database  tree.  In  the  same  fashion,  we  create  a  corresponding  OCU-SUBSYSTEM  object 
for  each  SUBSYSTEM-OBJ,  and  an  object  of  the  same  class  name  for  each  instance  of  a 
PRIMITIVE-OBJ  subclass  object.  At  this  time,  we  copy  aU  the  attributes  the  Domain 
Engineer  defined  to  be  “edit-attributes”  of  the  domain-specific  primitives  from  the  Refine 
(AVSI)  object  base  to  the  ITASCA  objects.  As  we  create  all  the  database  objects  up  to  this 
point,  we  save  the  object-identifier  created  by  ItaSCA  in  a  mapping  whose  domain  is  the 
name  of  the  corresponding  AVSI  tmiquely  named  object. 

At  this  point,  we  are  ready  to  add  the  structure  to  our  database  application.  Start¬ 
ing  with  the  APPLICATION-COMPONENTS  attribute  of  the  OCU- APPLICATION  ob¬ 
ject,  we  place  the  object  identifiers  these  names  map  to  in  the  ICO-SUBSYSTEMS  at¬ 
tribute  of  the  OCU-APPLICATION.  We  also  make  a  call  to  a  subroutine  that  saves  the 
APPLICATION-OBJ ’s  update  function.  Next,  we  iterate  over  all  the  SUBSYSTEM-OBJ 
objects  contained  in  the  tree,  calling  a  subroutine  to  save  the  SUBSYSTEM-OBJ ’s  update 
function.  Another  subsystem  csdl  iterates  over  the  set  of  all  SUBSYSTEM-OBJs,  using 
the  CONTROLLEES  attribute  names  to  store  the  corresponding  object  identifiers  in  the 
ICO-ELEMENTS  attributes  of  each  OCU-SUBSYSTEM  object. 

The  final  step  to  complete  oiu:  hierarchy  is  to  iterate  over  all  the  IMPORT-OBJ 
eind  EXPORT-OBJ  objects,  creating  OCU-INPUT  and  OCU-OUTPUT  objects  in  the 
database  and  linking  them  to  the  correct  OCU-PRIMITIVE  objects  based  on  the  name 
attributes  stored  in  the  AVSI  objects.  We  create  eiU  the  OCU-OUTPUT  objects  first,  so 
when  we  create  the  OCU-INPUT  objects  we  can  associate  them  with  the  correct  source 
OCU-OUTPUT. 

Note  that  we  consider  2ill  the  work  done  to  save  an  entire  application  to  be  one 
transaction  for  the  database.  If  at  2iny  point  in  the  process  something  goes  wrong,  we 
abort  the  entire  transaction,  returning  the  database  to  a  non-corrupted  state.  If  the 
entire  process  succeeds,  we  commit  the  transeiction,  and  the  database  contains  the  saved 
application. 


4-16 


4-5.3  Loading  Composed  Applications  from  ITASCA.  Since  we  save  the  entire 
OCU  hierarchy  within  the  database,  we  can  load  the  application  back  into  the  RE¬ 
FINE  object  base  in  a  single,  top-down  pass  through  the  tree.  After  selecting  an  OCU- 
APPLICATION  from  the  database,  we  create  a  SPEC-OBJ  in  the  REFINE  object  base  to  be 
the  tree  root,  and  create  an  APPLICATION-OBJ  and  place  it  as  a  leaf.  We  iterate  over  the 
ICO-SUBSYSTEMS  attribute  of  the  OCU-APPLICATION,  making  calls  to  a  subprogram 
for  creating  the  appropriate  SUBSYSTEM-OBJ  objects.  This  subprogram  abo  creates  the 
instances  of  PRIMITIVE-OBJ  subclasses,  as  well  as  calling  itself  recursively  to  build  lower 
level  subsystems.  Since  all  the  relationships  in  the  Refine  object  base  are  based  on  the 
n2Lmes  of  the  objects,  we  can  fill  the  attributes  in  as  we  create  each  object.  When  all  the 
objects  have  been  created,  we  call  the  necessary  housekeeping  functions  that  used  to  be 
called  after  parsing  em  application  from  a  file,  and  the  apphcation  is  available. 

4-6  Domain-Definition  Object  Model  Development 

One  of  the  goals  of  our  work  was  to  abstrzwrt  implementation-specific  details  away 
from  the  domain  expert  and  Application  Specialist.  We  want  the  user  of  the  application 
composition  system  to  be  able  to  work  in  domain-specific  terms  to  compose  applications 
in  that  domain.  One  area  where  we  recognized  we  could  provide  an  addition^d  level  of 
abstraction  was  the  generation  of  the  domain-specific  schema  for  the  database  and  the 
source  code  for  the  domain  primitives.  We  knew  that  if  we  could  formally  capture  the 
domain-knowledge  used  to  generate  the  schema  and  the  source  code,  we  could  automate 
the  process.  The  first  step  was  to  aneilyze  the  type  of  data  needed  to  produce  both 
the  schema  and  the  source  code  for  primitive  objects  and  to  create  an  object  model  of 
domain-specific  data.  We  then  had  to  provide  tools  to  tremsform  the  domain  knowledge 
into  database  schemas  zmd  source  code  for  domain  primitives.  A  more  detailed  description 
of  this  process  follows. 

4-6.1  Abstraction  of  Domain-Oriented  Object  Models.  Our  goal  here  wm  to 
produce  an  object  model  of  object  models  (a  meta-model).  Specifically,  we  wanted  to 
be  able  to  create  what  we  called  a  domain-definition  object  model.  With  this  domain- 
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Figure  4.7  Domain-Definition  Object  Model 

definition  object  model  we  wanted  to  be  able  to  capture  all  the  information  necessary 
to  define  the  domain-specific  database  schema  and  the  primitives  for  a  given  application 
domain.  The  domain  model  we  produced  for  the  logic  circuits  domain  (Figure  4.1)  is 
an  example  of  a  domain  model  capable  of  providing  that  type  of  domain-specific  data. 
Using  Rumbaugh’s  (29)  OMT  we  analyzed  the  domain  of  domain-specific  object  models 
to  produce  the  domain-definition  object  model  depicted  in  Figiure  4.7.  The  logic  circuits 
domain  object  model  depicted  in  Figure  4.1  is  an  instance  of  the  type  of  object  model 
the  Dommn  Engineer  is  able  to  describe  using  the  domain-definition  object  model.  A 
description  of  the  domain-definition  object  model  (Figure  4.7)  follows. 
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1.  DOMAIN-DEF  -  The  DOMAIN-DEF  class  is  a  container  class  encapsulating  all 
defined  domains.  It  has  a  name  attribute  and  a  description  attribute,  both  of  type 
string.  In  our  example,  the  name  attribute  of  our  instance  of  DOMAIN-DEF  has 
the  v2Jue  “Circuits”  identifying  it  as  the  circuits  domain.  The  container  class  that 
acts  as  a  handle  for  a  domzdn  comes  from  the  “Name”  attribute  of  an  instance  of 
the  DOMAIN-DEF  claiss  (refer  to  the  “Circuits”  class  in  Figxire  4.1).  Instances  of 
the  OBJECT-CLASS  class  in  Figure  4.7  represent  all  the  classes  below  “Circuits” 
in  Figure  4.1.  The  DOMAIN-DEF  class  has  no  association  with  the  Data-Object 
class  or  the  Refine-Function  class,  which  is  how  we  define  attributes  and  operations 
respectively.  This  explains  why  we  implemented  “Circuits”  as  a  container  class  with 
no  attributes  or  operations.  The  Domain  Engineer  can  use  the  optioned  description 
attribute  of  the  DOMAIN-DEF  class  and  all  other  classes  in  the  domain-definition 
object  model  to  help  document  the  purpose  of  an  object  class. 

2.  FASL-OBJ  -  The  FASL-OBJ  class  represents  instances  of  REFINE  executables.  The 
“Has-Refine-Executable”  relationship  connects  the  FASL-OBJ  class  to  the  DOMAIN- 
DEF  class.  Once  a  domain  has  been  completely  defined  and  a  REFINE  executable  has 
been  generated,  the  “Has-Refine-Executable”  relationship  will  connect  the  DOMAIN- 
DEF  with  an  instance  of  the  FASL-OBJ  class.  If  a  domain  exists,  but  a  Ref*we 
executable  has  not  yet  been  generated,  then  no  instance  of  the  FASL-OBJ  class  will 
exist  and  the  “Has-Refine-Executable”  relationship  will  be  imdefined.  The  possibility 
that  a  domain  may  or  may  not  have  a  FASL-OBJ  associated  with  it  at  emy  given  time 
explains  why  the  “Has-Refine-Executable”  relationship  has  a  zero-to-one  multiplicity 
on  the  FASL-OBJ  clciss. 

3.  OBJECT-CLASS  -  The  OBJECT-CLASS  class  defines  the  classes  in  a  domciin- 
specific  object  model.  An  OBJECT-CLASS  has  three  attributes:  nzune,  superclaiss, 
and  description.  In  our  exeunple  in  Figure  4.1,  the  SWITCH,  GATE,  LED,  and  MUX 
classes  are  adl  insteinces  of  a  speciedization  of  OBJECT-CLASS.  The  GATE  instance, 
for  excimple,  would  have  the  following  attribute  values: 

•  name  :  “gate” 

•  superclass  :  “circuit” 
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•  description  :  Some  description  of  the  class  that  would  aid  an  Application 
Specialist  in  understanding  this  object’s  purpose. 

Note  that  the  DOMAIN-DEF  clriss  contains  an  “is-composed-oP  relationship  to  one 
or  more  inst2uices  of  the  OBJECT-CLASS  class.  In  the  circuits  example  of  Figure  4.1, 
there  are  fifteen  instsmces  of  OBJECT-CLASS. 

•  CIRCUIT-ARTIFACT 

•  GATE 

•  SWITCH 

•  LED 

•  COMPONENT 

•  AND-GATE 

•  OR-GATE 

•  NAND-GATE 

•  NOR-GATE 

•  NOT-GATE 

•  COUNTER 

•  DECODER 

•  MUX 

•  JK-FLOP-FLOP 

•  HALF-ADDER 

4.  DATA-OBJECT  -  The  DATA-OBJECT  class  defines  the  attributes  of  an  object 
class.  Note  that  the  “is-composed-of”  relationship  from  OBJECT-CLASS  to  DATA- 
OBJECT  contains  a  zero-to-msmy  multiplicity.  This  allows  an  instwce  of  OBJECT- 
CLASS  to  have  zero-to-many  attributes  defined.  The  SWITCH  OBJECT-CLASS 
hais  four  instzuices  of  DATA-OBJECT  associated  with  it. 

•  Delay  Attribute 

—  Name  :  “delay” 

—  Type  :  “integer” 

-  Init-Val  :  “0” 

-  Kind-Of :  OCU-ATTRIBUTE 

-  Category  :  “signal” 

-  Description  :  “descriptive  text” 

•  Debounced  Attribute 
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-  Name  :  “debounced” 

-  Type  :  “boolean” 

-  Init-Val  :  “nil” 

-  Kind-Of  :  OCU- ATTRIBUTE 

-  Category  :  “signal” 

-  Description  :  “descriptive  text” 

•  Position  Attribute 

-  Name  :  “position” 

-  Type  ;  “symbol” 

-  Init-Val  :  on 

-  Kind-Of  :  OCU- ATTRIBUTE 

-  Category  :  “signal” 

-  Description  :  “descriptive  text” 

•  outl  Output 

-  Name  :  “outl” 

-  Type  :  “boolean” 

-  Init-Val  :  “nil” 

-  Kind-Of :  OCU-OUTPUT 

-  Category  :  “signal” 

-  Description  :  “descriptive  text” 

The  LED  OBJECT-CLASS  has  two  instances  of  DATA-OBJECT  associated  with  it. 

•  Color  Attribute 

-  Name  :  “color” 

-  Type  :  “symbol” 

—  Init-Val  :  red 

-  Kind-Of  :  OCU- ATTRIBUTE 

-  Category  :  “signed” 

—  Description  :  “descriptive  text” 

•  ini  Input 

-  Name  :  “ini” 

-  Type  :  “boolean” 

-  Init-Val  :  “nil” 

-  Kind-Of :  OCU-INPUT 

-  Category  :  “signal” 

-  Description  :  “descriptive  text” 

All  the  object  classes  depicted  in  Figure  4.1  are  defined  similarly. 
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5.  ABSTRACT  -  All  instances  of  the  OBJECT-CLASS  class  are  either  ABSTRACT  or 
CONCRETE  because  of  the  is-a  relationship  from  OBJECT-CLASS  to  ABSTRACT 
and  CONCRETE.  If  an  instance  of  OBJECT-CLASS  is  w  ABSTRACT  class,  it 
requires  no  eidditional  information.  Hence,  the  ABSTRACT  class  has  no  attributes 
or  relationships.  Using  the  circuits  exjunple  again  in  Figmre  4.1,  GATE  and  COM¬ 
PONENT  are  both  examples  of  an  ABSTRACT  OBJECT-CLASS.  The  attributes 
shown  on  GATE  and  COMPONENT  in  Figure  4.1  are  actually  inherited  by  their 
subclasses  when  instances  of  those  subclasses  sure  instantiated.  Recall  that  these 
are  not  class  attributes,  so  it  is  just  the  attribute  description  that  is  inherited,  not 
th?  attribute  value.  The  reason  we  need  to  define  the  GATE  class  as  sin  abstract 
class  is  because,  in  our  domsiin,  it  msJces  no  sense  to  create  an  instsmce  of  a  GATE 
unless  it  is  further  defined  sis  sin  AND,  OR,  NAND,  NOR,  or  NOT  GATE.  Similsurly, 
OBJECT-CLASS  is  an  abstrswrt  class  within  our  domain-definition  object  model 
depicted  in  Figure  4.7.  It  msJces  no  sense  to  create  sm  OBJECT-CLASS  unless  it  is 
created  as  an  ABSTRACT  or  CONCRETE  OBJECT-CLASS. 

6.  CONCRETE  -  Like  ABSTRACT,  CONCRETE  is  a  specisdization  of  the  abstrsict 
clsiss  OBJECT-CLASS  in  the  domsun-definition  object  model  depicted  in  Figure  4.7. 
CONCRETE  inherits  the  attributes  of  OBJECT-CLASS,  just  sis  instsmces  of  AB¬ 
STRACT  do.  An  instance  of  the  CONCRETE  class,  however,  is  composed  of  one 
or  more  instances  of  the  REFINE-FUNCTION  class.  The  resison  for  this  is  that  sdl 
CONCRETE  clsisses  in  our  domsiin  model  represent  primitives  of  that  domsiin,  sind 
each  primitive  must  have  at  least  one  update  function.  An  example  of  a  CONCRETE 
object  in  Figure  4.1  is  the  Coimter.  Besides  the  attributes  it  inherits  from  its  psurent 
clsisses  in  the  circuits  object  model,  it  has  the  following  attributes:  the-count,  clock, 
reset,  Isb,  msb,  suid  msoc-count.  If  you  look  at  the  Refine  implementation  of  the 
counter  in  Appendix  B,  you  will  see  that  it  has  one  update  function.  Counter, 
then,  would  be  sissociated  with  only  one  instance  of  the  REFINE-FUNCTION  class. 
AND-GATE,  on  the  other  hsind,  has  two  update  functions,  “AND-GATE-UPDATE” 
and  “AND-GATE-UPDATE2,”  so  it  would  be  sissociated  with  two  instsmces  of  the 
REFINE-FUNCTION  class. 
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foxinat(d«biig-oii,  "COUlTER-UPOiTEl  os  nani«(conBt«r)) ; 

let  (clock  :  boolean  ■  get-iBport(' clock,  enbejetem,  coaster), 
reset  :  boolean  •  get-import (’reset,  snbsystea,  coaster)) 

(if  reset  then 

COOITER-THE-COUIT (counter)  <-  0 
elseif  clock  then 

COOTTER-THE-COniT(cottnter)  <-  COniTER-THE-COinrr(coaster)  +1 

): 

(if  COtJHTER-THE-COUMT (counter)  > 

get-coefficient-valae(connter,  ’mar-count)  then 
COtntTER-THE-COnrr(counter)  <-  0 

): 

if  COdlTER-THE-COniKconnter)  -  0  then 
set-export (subsystem,  counter,  ’msb,  nil); 
set-export (subsystem,  counter,  ’Isb,  nil) 
elseif  COlTlTER-THE-COtnfT(counter)  •  1  then 
set-export (subsystem,  counter,  ’msb,  nil); 
set-export (subsystem,  counter,  ’Isb,  true) 
elseif  COinrTER-THE-COUIT(coanter)  >  2  then 
set-export (subsystem,  counter,  ’msb,  true); 
set-export (subsystem,  counter,  ’Isb,  nil) 
elseif  COUITER-THE-COUllT(counter)  *  3  then 
set-export (subsystem,  counter,  ’msb,  true); 
set-export (subsystem,  counter,  ’Isb,  true) 


Figure  4.8  Refine  Code  for  Update  Function 

7.  REFINE-FUNCTION  —  The  REFINE-FUNCTION  class  captures  the  update  func¬ 
tions  of  a  CONCRETE  clziss.  To  continue  using  the  counter  as  an  example,  the  single 
instance  of  the  REFINE-FUNCTION  class  associated  with  counter  would  be: 

•  Type  :  “OCU-Active-Update” 

•  Name  :  “COUNTER-UPDATEI” 

•  Code  :  (See  Figure  4.8) 

•  Description  :  “descriptive  text” 

Figmre  4.9  is  an  instance  diagram  of  the  Domain-Definition  object  model  instwtiated 
for  the  logic  circuits  domeun  pictiured  in  Figure  4.1.  Take  note  that  this  is  ein  instance 
diagram  of  only  a  small  subset  of  the  object  model  depicted  in  Figure  4.1  for  purposes  of 
illustration.  Notice  that  the  Domain-Definition  instance  in  Figure  4.9  has  the  name  value 
“CIRCUITS”  which  corresponds  to  the  CIRCUITS  contsdner  class  near  the  top  of  Fig¬ 
ure  4.1.  In  the  ICO-OBJECT-CL ASSES  relationship  of  the  DOMAIN-Definition  instance 
in  Figure  4.9  are  four  CONCRETE  OBJECT-CLASS  instances  and  two  ABSTRACT 
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Figure  4.9  Domain-Definition  Instance  Diagram  for  Logic  Circmts  Domain  Subset 

OBJECT-CLASS  instances.  Each  one  of  these  can  be  traced  back  to  CONCRETE  and 
ABSTRACT  OBJECT-CLASSES  respectively  on  the  object  model  in  Figme  4.1.  For 
example,  look  at  the  CONCRETE  instamce  on  Figure  4.9  with  the  name  value  LED 
and  the  superclass  value  Circuit-Artifact.  Note  that  it  has  a  DATA-OBJECT  in  its 
ICO-DATA-OBJECTS  relationship,  and  that  DATA-OBJECT  is  an  OCU-ATTRIBUTE 
with  the  n£une  COLOR.  Now  refer  b2K:k  to  Figure  4.1  and  find  the  CONCRETE  class 
labeled  LED.  Its  superclass  is  Circuit-Artifact  and  it  has  a  color  attribute.  Recall  that 
the  instance  diagram  in  Figme  4.9  only  represents  a  small  subset  of  the  whole  instance 
diagram  for  Figture  4.1,  but  the  reader  should  be  able  to  trace  every  element  in  Figure  4.9 
back  to  a  corresponding  element  pictmed  in  Figure  4.1. 
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Satisfied  that  the  domain-definition  object  model  in  Figure  4.7  was  capable  of  cap¬ 
turing  the  domain  knowledge  in  a  domain  model  like  that  in  Figure  4.1,  we  implemented 
the  domain-definition  object  model  as  a  database  schema  in  the  OODBMS.  The  following 
sections  describe  the  process  of  populating  the  database  with  a  description  of  an  application 
domain,  emd  generating  a  database  schema  and  REFINE  source  code  for  primitive  objects 
from  that  data. 

4-6.2  Populating  Database  with  Domain  Knowledge.  One  of  the  tools  available 
with  the  Itasca  OODBMS  is  its  Active  Data  Editor  (ADE^“).  It  allows  the  user  of 
the  OODBMS  to  create  instances  of  the  classes  in  the  domain-definition  object  model  to 
describe  a  given  application  domain.  We  foimd  from  experience  that  the  object  model 
we  developed  was  very  good  for  defining  the  inheritance  relationships,  showing  abstract 
versus  concrete,  and  identifying  attributes,  but  it  got  busy  very  quickly  when  we  tried  to 
put  a  lot  of  detjul  on  it.  For  that  reason,  we  developed  some  data  collection  forms  to  use 
in  conjunction  with  the  object  model  to  make  it  simpler  for  the  Domain  Engineer  to  input 
data  into  the  database.  Appendix  A  has  a  description  of  each  data  collection  form,  as 
well  as  example  completed  forms  for  ^dl  the  primitives  in  the  logic  circuits  domain.  These 
eire  just  tools  to  help  orgamize  the  data,  but  we  foimd  it  very  helpful  to  have  these  all 
filled  out  before  attempting  to  enter  the  data  into  the  database.  Appendix  D  contains  the 
scenario  of  defining  the  logic  circuits  domain  using  the  domain-definition  object  model  and 
the  Itasca  ADE. 

Once  the  Domain  Engineer  enters  the  domain  knowledge  into  the  database,  eis  we 
did  in  Appendix  D,  we  have  access  to  enough  domain  knowledge  to  produce  a  database 
schema  capable  of  storing  instances  of  domain  primitives.  The  domain  knowledge,  coupled 
with  some  knowledge  of  the  structure  of  the  application  composer’s  source  code,  enables 
us  to  generate  Refine  source  code  for  the  primitive  objects  of  the  domain.  The  next  two 
sections  describe  these  two  capabilities. 

4-6.3  Automatic  Generation  of  Database  Schema.  With  knowledge  of  the  domain 
now  captured  in  the  database,  we  needed  to  write  a  set  of  database  methods  to  use  that 
knowledge  to  generate  a  database  schema  for  storing  domain-specific  data.  The  databeise 
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Figure  4.10  Itasca  Schema  Template 


(d«f-claas  CIKCnrrS 
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Figure  4.11  ITASCA  Class  Definition  of  CIRCUITS  Class 

methods  serve  as  a  template  for  the  commands  needed  to  generate  a  database  schema. 
The  template  for  defining  a  class  in  the  database  schema  is  shown  in  Figure  4.10. 

There  can  be  from  zero  to  many  attributes  defined  for  a  class.  In  the  above  case 
three  attributes  are  defined.  We  do  not  ciurently  use  class  attributes,  so  the  class  attributes 
field  will  always  be  empty.  The  words  in  upper-case  represent  the  “place  holders”  in  the 
template  that  are  filled  with  instance  data  from  the  DOMAIN-DEF  object  model. 

To  continue  with  the  logic  circuits  domain,  the  instance  of  the  DOMAIN-DEF  class 
in  Figure  4.9  h^  the  name  dRCUTTS.  Recall  too  that  instances  of  DOMAIN-DEF  serve 
as  our  container  class  and  inherit  firom  the  architecture  primitive.  The  code  generated 
from  this  instance  data  is  in  Figure  4.11. 

The  algorithm  the  database  method  follows  is  to  then  visit  eeich  object  class  in 
the  ico-object-classes  relationship  and  produce  the  code  for  each  of  these  object  classes. 
Some  object  classes  have  an  ico-data-objects  relationship.  So,  while  visiting  those  object 
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Figure  4.12  ItaSCA  Class  Definition  of  the  GATE  Class 

classes,  all  DATA-OBJECTS  in  the  ico-data-objects  relationship  are  visited  to  produce  the 
appropriate  code.  The  code  for  the  instance  of  ABSTRACT-CLASS  named  GATE  is  in 
Figure  4.12. 

Note  that  the  3  DATA-OBJECITS  in  the  ico-data-objects  relationship  were  visited 
and  their  corresponding  code  was  produced.  The  ITASCA  code  to  generate  the  database 
schema  for  the  entire  logic  circuits  domain  is  in  Appendix  B. 

^.6.^  Automatic  Generation  o/ Refine  Source  Code.  We  also  needed  to  write 
a  set  of  methods  to  use  the  domain  knowledge  captured  in  the  database  to  produce 
Refine  source  code  for  the  primitive  objects  of  the  domain.  The  same  general  process 
used  to  generate  the  database  schema  is  also  used  to  generate  the  REFINE  source  code. 
The  methods  encapsulate  the  knowledge  that  represents  a  template  for  defining  domain 
primitives  in  Refine  source  code.  The  instances  of  data  in  the  DOMAIN-DEF  object 
model  are  visited  in  the  proper  order  to  fiU  in  the  blanks  in  the  template.  The  Refine 
source  code  generated  by  these  methods  can  be  found  in  Section  B.2.  This  code  can  be 
compiled  by  REFINE,  and  be  used  in  the  REFINE  Object  Base  to  define  the  logic  circuits 
domain  for  the  application  composer. 
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Incorporation  of  Concurrent  Reaearch  Reaulta 

There  were  a  number  of  concurrent  r^earch  efforts  on  the  domain-oriented  applica¬ 
tion  composition  environment  that  we  needed  to  stay  abreast  of,  especially  in  the  au-ea  of 
improving  the  visual  interface  (8)  and  support  for  an  application  executive  (11,  36). 

4.7.1  Changes  for  the  Visual  Interface.  Cossentine  (8)  completely  changed  the 
face  of  Architect’s  visual  interfaure  by  introducing  bitmapped  icons  for  representing  domain 
primitive  objects.  Our  effort  in  supporting  these  changes  were: 

1.  Support  the  storage  of  the  bitmapped  icon  definitions  within  the  database,  allowing 
them  to  be  read  directly  from  the  database  rather  than  separate  files. 

2.  Allow  the  Domain  Engineer  to  associate  the  name  of  bitmapped-icons  to  correspond 
to  primitive  definitions  in  his  domain  model. 

3.  Ensure  our  source  code  generation  method  provided  the  necessary  code  to  read  in 
the  bitmap  information  from  the  database  when  the  domain  model  gets  loaded  from 
the  database  to  the  Architect  object  base  in  REFINE. 

4.7.2  Addition  of  Application  Executive  Services.  Welgan  (36)  researched  the 
ability  to  have  application  executives  support  different  operating  environments,  to  include 
discrete  event  simulation  and  real-time  applications.  Although  we  do  not  support  any  of  the 
new  application  areas  he  worked  on,  the  domain  model  representation  for  the  OCU  model 
was  modified  to  support  his  rese2U'ch.  Specifically,  imports  and  exports  from  lower  level 
subsystems  were  moved  up  to  the  highest  level  subsystem.  These  changes  were  application 
specific,  so  they  did  not  affect  our  abstract  OCU  database  schema.  However,  our  mappings 
for  correctly  saving  ^md  restoring  these  objects  had  to  be  modified  to  support  these  changes. 

4.8  Conclusion 

In  this  chapter  we  introduced  the  logic  circuits  domain  as  the  validating  domain 
for  our  work.  We  then  developed  an  object  model  of  the  logic  circuits  domain  using 
Rumbaugh’s  Object  Modeling  Technique.  We  presented  our  object  model  of  the  OCU 
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Architecture  and  introduced  the  concept  of  the  Domain-Definition  Object  Model.  By 
populating  the  Domain-Definition  Object  Model  with  knowledge  of  a  domain,  we  showed 
that  we  could 

1.  Automatically  generate  in  the  technology  base,  the  database  schema  for  the  newly 
defined  domain,  and 

2.  Automatically  generate  the  Refine  source  code  to  define  the  domain  in  the  Domain- 
Oriented  Application  Composition  Environment. 

Finally,  we  described  the  integration  of  the  Itasca  OODBMS  version  of  the  technol¬ 
ogy  base  with  the  original  file-based  version  of  Architect.  In  the  next  chapter  we  describe 
the  testing  we  conducted  to  validate  oiu:  work.  We  describe  the  stand-alone  testing  we  did 
for  each  of  the  functional  components  and  the  integration  testing  we  did  to  ensure  all  the 
pieces  worked  together  properly. 
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V.  Validation  and  Analysis 


5. 1  Introduction 

The  validation  dom2dn  used  for  AVSI  with  database  capabilities  was  digital  circuits, 
the  same  domain  used  by  Anderson  and  Randour  for  Architect.  This  chapter  discusses 
the  validation  of  our  research  using  this  domain  and  presents  an  assessment  of  AVSI  with 
datab^ise  capability. 

Since  we  did  our  development  for  this  research  in  parallel  with  each  other,  each  branch 
was  tested  separately,  followed  by  a  complete  test  of  the  entire  project.  The  following 
sections  siunmarize  the  testing  methodology  and  results. 

5.2  Testing  of  AVSI  with  Database  Capabilities 

As  noted  before,  we  developed  the  database  capabilities  for  AVSI  using  a  rapid¬ 
prototyping,  evolutionary  development  approach.  The  goal  was  to  be  able  to  store  and 
retrieve  applications  composed  in  AVSI  sessions.  Testing,  in  a  rapid-prototyping  approach, 
is  done  in  parallel  and  in  conjunction  with  development. 

We  used  the  following  test  objectives: 

1.  The  ability  to  successfully  store  a  composed  application  in  the  database. 

(a)  Verify  each  object  in  the  REFINE  object  bs«e  that  is  supposed  to  be  saved  in 
the  database  gets  instantiated. 

(b)  Verify  the  attribute  values  of  each  object  created  in  the  database. 

(c)  Verify  the  structural  relationships  of  the  application  stored  in  the  database. 

2.  The  ability  to  successfully  load  em  application  stored  in  the  database  into  the  REFINE 

object  base. 

(a)  Verify  that  each  object  stored  in  the  database  gets  instantiated  in  the  Refine 
object  base. 

(b)  Verify  the  attribute  values  of  each  object  created  in  the  REFINE  object  base. 
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(c)  Verify  the  structural  relationships  of  the  application  in  the  Refine  object  base. 

(d)  Ensure  the  application  loaded  into  the  REFINE  object  base  correctly  executes. 

(e)  Store  the  application  loaded  from  the  database  to  a  file,  and  compare  it  with 
the  file  created  when  the  application  was  originsdly  composed. 

Before  beginning  development  of  code,  we  first  had  to  instsintiate  the  Itasca  schema 
developed  for  the  circuits  domain  in  Figure  4.1.  We  input  this  information  directly  into 
Itasca  using  the  schema  editor  tool  provided. 

The  first  phase  of  development  and  testing  involved  saving  an  application  into  the 
database.  The  goal  was  to  load  an  entire  application  from  the  file-based  technology  base 
and  save  it  to  the  database.  After  each  attempt,  we  walked  through  the  instances  contained 
in  the  database,  verifying  that  all  necessary  objects  existed  and  that  each  contained  the 
correct  data.  This  was  accomplished  incrementally.  First,  we  attempted  to  just  create  the 
necessary  objects;  next,  we  copied  and  verified  the  object’s  attribute  values;  finally,  we 
added  the  structure  by  updating  and  verifying  the  relationships  between  objects.  After 
each  iteration  was  verified,  we  deleted  all  of  the  objects  in  the  database  to  begin  the  next 
step.  Upon  complete  verification  of  the  database  instances,  this  phase  of  development 
was  almost  complete.  It  could  not  be  completely  verified  until  the  next  phase  was  also 
completed. 

The  next  phase  of  development  and  testing  built  on  the  first  phase;  now  we  must 
be  able  to  load  the  saved  application  from  the  database  back  into  the  REFINE  object  base 
during  an  AVSI  session.  Again,  this  was  done  incrementally,  first  building  the  objects, 
then  updating  the  attributes.  We  m2inucilly  verified  these  steps  using  the  object  browser 
feature  of  Refine.  After  peissing  the  manual  verification,  we  verified  that  the  application 
would  execute  properly  within  the  AVSI  session.  The  final  verification  involved  saving 
the  application  loaded  from  the  database  back  out  to  the  file-b£ised  technology  base  imder 
a  different  file  name.  We  compared  tne  original  source  file,  used  in  one  AVSI  session  to 
populate  the  database,  with  the  file  generated  under  a  separate  session  and  saved  out  to 
file.  We  repeated  this  fin2d  verification  for  each  of  the  validated  applications  contained  in 
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the  file-based  technology  base;  after  completing  this  verification,  the  database  technology 
base  contained  the  same  information  as  the  file-based  version. 

5.3  Testing  of  Database  Methods 

We  developed  two  sets  of  database  methods  that  traverse  the  DOMAIN-DEF  struc¬ 
tures  in  the  Itasca  database,  extracting  domain  knowledge  to  produce  domain  and  schema 
definitions  for  the  Domain-Oriented  Application  Composition  Environment.  Before  testing 
could  start,  we  had  to  instantiate  the  Itasca  schema  for  the  DOMAIN-DEF  object  model. 
We  did  this  by  using  the  interactive  ITASCA  Schema  Editor.  We  then  populated  the 
database  with  the  definition  of  the  logic  circuits  domain.  We  used  the  ITASCA  Active  Data 
Editor  to  do  this,  just  as  a  Domain  Specialist  would  be  expected  to  do  when  defining  a  new 
domain.  Once  we  had  the  knowledge  of  the  logic  circuits  domain  loaded  into  the  database, 
we  could  test  the  two  sets  <  methods  we  developed. 

We  used  the  following  test  objectives: 

1.  The  ability  to  represent  domain  knowledge  with  instances  of  the  Domain-Definition 
object  model. 

2.  The  ability  to  automatically  generate  a  database  schema  definition  in  the  ITASCA 
databjise  from  inst2uices  of  the  Domain-Definition  object  model. 

3.  The  ability  to  automatically  generate  Refine  source  code  to  load  a  domain  definition 
into  the  Refine  Object  Base  from  instances  of  the  Domain-Definition  object  model. 

5.3.1  Testing  Methods  that  Generate  Database  Schemas.  The  first  step  in  testing 
the  schema  generation  methods  was  to  manually  derive  the  set  of  ITASCA  commzinds  needed 
to  create  a  databeise  schema  for  the  logic  circuits  domain.  We  verified  that  our  set  of 
commands  was  syntewrtically  correct  by  using  them  to  instantiate  the  schema  intereictively 
through  the  Itasca  Schema  Editor.  At  this  point  we  manuedly  verified  that  the  schema 
we  generated  would  be  sufiScient  to  store  instances  of  the  domain  primitives.  We  then 
executed  the  set  of  methods  to  automatically  generate  the  database  schema  for  the  logic 
circuits  domain,  sending  the  output  to  a  file.  Next  we  compared  the  schema  generation 
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commands  produced  by  the  methods  with  the  ones  we  had  produced  manually.  We  deferred 
the  funct'onal  testing  of  the  schema  until  integration  testing  when  the  database  lo2ui  and 
retrieve  capabilities  would  2dso  be  available. 

5.3.2  Testing  Methods  that  Generate  REFINE  Source  Code.  We  took  a  similau: 
approach  to  testing  this  set  of  methods.  In  this  case,  we  already  had  source  code  to  generate 
the  logic  circuits  domain  from  the  baseline  Domain-Oriented  Application  Composition 
System.  We  executed  the  set  of  methods  to  automatically  generate  the  REFINE  source 
code  for  the  logic  circuits  domain,  sending  the  output  to  a  file.  Although  the  format  was 
somewhat  different  (indentations,  line  spacing,  etc),  we  could  verify  that  the  automatically 
generated  code  would  produce  the  same  results  in  the  REFINE  object  base  as  the  baseline 
code.  We  further  tested  our  code  by  starting  an  Architect  session  Jind  loading  the  domain 
from  our  file  instead  of  the  baseline  files.  We  then  used  Architect  to  compose  and  execute 
applications  in  the  logic  circuits  domain  to  verify  that  Architect  still  worked  properly. 

5.4  Testing  of  Integrated  System 

Now  that  each  piece  of  the  project  had  passed  stand-alone  testing,  it  was  time  to  put 
it  all  together.  Before  integration  testing  began,  we  deleted  all  instance  data  and  schema 
definitions  generated  from  stand-2done  testing  described  in  Section  5.2  and  Section  5.3.  We 
now  had  a  clean  enviromnent  for  integration  testing. 

We  first  played  the  role  of  the  Dommn  Engineer,  using  the  Itasca  ADE  to  enter 
the  circuits  dommn  definition.  We  then  initialized  an  AVSI  session  in  REFINE,  using 
our  database  version.  We  ran  the  subprogram  provided  for  the  Domain  Engineer  which 
generates  the  Itasca  schema  for  a  domain  and  also  generates  and  compiles  the  Refine 
source  code  for  the  AVSI  domain  model.  If  no  errors  aire  encountered,  the  database 
schema  is  committed  and  the  Refine  executable  is  saved  in  the  databcise.  When  this 
was  successful,  we  manu^llly  verified  the  schema  using  the  schema  editor  and  verified  the 
source  code  by  examining  the  file.  We  cJso  intentiondly  introduced  errors  to  ensure  that 
our  error  detection  functioned  properly. 
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Having  successfully  completed  and  verified  the  Domain  Engineer  function,  we  shut 
AVSI  down.  We  now  needed  to  verify  that  the  products  created  could  be  used  by  an 
Application  Specialist.  We  started  a  new  AVSI  session,  and  composed  a  new  application. 
After  verifying  the  application  could  execute  properly,  we  saved  a  copy  of  it  to  both  the 
file  system  and  the  database.  We  would  use  the  file  system  version  later  for  verification. 

Once  again  we  shut  AVSI  down  and  started  a  new  session.  We  reloaded  our  saved 
application  from  the  database  cind  verified  its  execution  within  the  AVSI  environment. 
Once  execution  was  verified,  we  saved  the  application  to  a  new  file  and  compared  this  to 
the  previously  saved  file.  Having  successfully  accomplished  this,  we  began  the  process  of 
loading  in  each  saved  application  from  the  file  system  and  saving  them  to  the  database. 
In  cinother  AVSI  session,  we  reloaded  etich  application  from  the  database,  verified  its 
execution,  saved  it  to  a  different  file,  and  compared  the  two  file  versions.  When  this  was 
completed,  we  agziin  had  an  exact  copy  of  the  file-based  technology  base  saved  in  the 
database. 

5.5  Validating  Support  for  Concurrent  Research  Results 

In  order  to  support  concmrent  research,  we  developed  our  changes  to  Architect  in 
isolation  stzurting  from  a  known  baseline.  As  eeich  successive  baseline  was  created  eind 
verified  by  other  researchers,  we  incorporated  and  tested  all  of  their  chsmges  into  our  code. 
This  kept  our  code  in  line  with  the  latest  baseline  during  our  development.  Each  time  a 
new  baseline  vfas  created,  we  worked  closely  with  its  developer  to  test  emy  new  functionality 
added,  as  well  as  to  verify  no  functionality  was  lost. 

5.6  Conclusion 

In  this  chapter  we  discussed  the  stand-alone  and  integration  testing  of  our  work. 
We  presented  the  test  objectives  for  each  functioned  component  emd  described  the  tests 
to  ensure  we  had  met  those  objectives.  Finally,  we  described  the  integration  testing  we 
did  to  ensure  all  the  functional  components  worked  properly  together.  The  results  of  our 
testing  verified  that  we  had  accomplished  the  goals  we  had  set  for  this  research.  In  the  next 
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chapter  we  discuss  the  conclusions  we  draw  from  our  research  and  make  recommendations 
for  future  research. 
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VI.  Conclusions  and  Recommendations 


The  objective  of  this  research  was  to  demonstrate  that  an  OODBMS  could  be 
used  as  a  Modeling  Library  for  managing  complex,  object-oriented  software  simulation 
components.  We  wanted  to  show  that  integrating  an  object-oriented  database  with  a 
domain-oriented  application  composition  system  would  create  a  software  engineering  envi¬ 
ronment  that  promotes  reuse  of  software  artifacts  stored  in  a  domain-oriented  technology 
base.  We  demonstrated  this  by  integrating  the  ITASCA  OODBMS  with  the  Architect 
domain-oriented  application  composition  system.  In  this  integrated  environment,  the 
OODBMS  serves  as  the  central  repository  (technology  base)  for  domain-specific  artifacts 
such  as  primitive  domain  components,  subsystems,  visuahzation  data,  and  composed 
applications. 

We  first  examined  the  current  literature  on  object-oriented  database  systems  in  an 
attempt  to  define  what  capabilities  they  could  provide,  and  how  they  could  aid  us  in 
reaching  our  goal.  Some  of  the  OODBMS  capabilities  we  felt  would  be  most  important  for 
integrating  Architect  into  this  software  engineering  enviromnent  were  a  dynamic  schema 
editing  capability  to  aid  in  rapid  prototyping,  support  for  a  Common  Lisp  environment  to 
be  compatible  with  Architect,  support  for  versioning  to  manage  multiple  versions  of  the 
same  data,  ^lnd  a  distributed  database  capability  to  allow  multiple  sites  to  access  the  data 
simultaneously.  We  selected  the  ITASCA  OODBMS  because  we  felt  it  provided  the  best 
mix  of  these  capabilities  for  our  new  software  engineering  environment. 

The  Architect  system  we  began  with  fimctioned  in  a  stand-alone  environment  (refer 
to  Figmre  3.2).  Figure  6.1  shows  the  environment  that  Architect  operates  in  as  a  result  of 
this  thesis.  Note  that  edl  of  the  file  system  interfaces  on  the  left-hand  side  of  the  figme 
are  simply  what  existed  before  our  integration  of  Architect  with  an  OODBMS.  None  of 
the  existing  file-based  function^llity  weis  removed,  and  the  added  database  fimctionality  is 
shown  on  the  right-hemd  side  of  Figure  6.1. 

A  new  load  file  is  provided  for  the  Application  Specialist  to  take  advantage  of 
the  databcise  capabilities  we  have  added.  DIALECT  emd  Intervista  are  automatically 
loaded  just  as  they  were  with  the  file-bjised  system;  however,  the  Architect  software  and 


6-1 


UNKFUe 


Figure  6.1  Big  Picture  of  the  New  Architect  Environment 


OCU  architecture  model  are  now  loaded  directly  from  the  database.  Unlike  the  previous 
implementation,  no  domain-specific  information  is  loaded  upon  startup.  The  first  time 
the  Application  Specialist  refers  to  a  domain,  that  domain’s  grammar,  domain  model, 
zmd  primitive  descriptions  are  generated  by  the  transformation  methods  and  loaded  in 
to  the  Refine  object  base.  Note  that  the  grammar  is  loaded  to  maintain  the  previous 
file-based  functionality  only;  the  database  implementation  eliminates  the  requirement  for 
the  domain-specific  graunmar.  When  the  primitive  descriptions  are  loaded  into  the  REFINE 
object  base,  the  icon  bitmap  information  is  also  loaded  from  the  database,  eliminating  the 
need  for  a  visual  grEunmar. 
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The  menu  for  loading  and  saving  applications  now  contains  options  to  specify  either 
the  database  or  the  file  system.  If  the  Application  Specialist  loads  from  the  database 
version  of  the  technology  base  emd  uses  the  database  for  storage  and  retrieval,  then  the 
requirement  for  running  REFINE  from  a  specified  directory  structure  is  eliminated.  This 
also  ensures  that  cdl  user’s  are  using  the  sjime  version  of  the  software,  as  it  is  now  centrally 
located.  In  the  file-beised  version,  m2iny  copies  of  the  source  code  can  exist  in  mwy  user’s 
directories,  making  configmration  management  much  more  difficult. 

We  developed  a  domain-definition  meta-model  using  Rumbaugh’s  object  modeling 
technique  (29)  to  define  a  class  of  domain-oriented  object  models.  We  instemtiated  this 
meta-model  as  a  schema  in  the  ITASCA  OODBMS,  Emd  populated  the  database  with  the 
description  of  an  object  model  we  developed  for  the  logic  circuits  domain.  With  this 
meta-model  resident  in  the  database,  the  Domain  Engineer  can  now  enter  the  results  of 
his  domjun  an<dysis  directly  into  the  database  using  the  ADE  tool  provided  with  Itasca. 
All  of  the  restrictive,  implementation-dependent  naming  conventions  have  been  removed, 
as  well  as  the  requirement  to  define  the  domain  in  a  target  implementation  language. 

Having  the  logic  circuits  domain  formedly  defined  in  the  database  allowed  us  to 
write  database  methods  to  transform  the  logic  circuits  object  model  into  other  formal 
representations.  We  wrote  two  such  sets  of  database  methods  to  operate  on  instances 
of  the  domain-definition  meta-model.  One  set  of  methods  encapsulates  the  knowledge 
necessEury  to  transform  domain-definition  data  into  the  REFINE  source  code  used  to  in¬ 
stantiate  a  domain  in  the  REFINE  object  base.  These  methods  automatically  generate 
the  implementation-dependent  naming  conventions  of  the  target  language.  The  other  set 
of  methods  transform  the  same  domain-definition  data  into  the  ITASCA  schema-creation 
commands  needed  to  store  dommn  artifacts  in  the  ITASCA  OODBMS.  As  the  technology 
beise  of  domains  emd  architectures  grows,  so  does  the  importance  of  having  automatic 
transformations  from  a  domain  description  to  other  formal  representations  required  by 
client  applications. 
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6. 1  Conclusions 


Using  2U1  OODBMS  for  the  technology  base  in  a  domain-oriented  application  com¬ 
position  environment  (and  other  object-based  software  engineering  tools)  provides  distinct 
advantages  over  using  a  file-based  technology  base.  We  successfully  demonstrated  this 
by  integrating  the  Itasca  Distributed  OODBMS  with  the  Architect  Domain-Oriented 
Application  Composition  System.  The  OODBMS  technology  baae  not  only  provides  all 
the  functioneility  previously  available  from  the  Architect  file-based  technology  base,  but 
provides  significant  additional  capabilities  as  well. 

The  greatest  benefit  of  our  prototype  domain-oriented  application  composition  en¬ 
vironment  is  the  ability  to  maintain  domain  data  in  object-model  form  throughout  its 
life-cycle.  The  Dom2iin  Engineer  can  input  the  object-model  for  a  domain  directly  into  our 
prototype  domain-oriented  application  composition  environment,  eliminating  the  need  to 
artificially  fiatten  the  object  model  into  a  structure  compatible  with  a  file-based  technology 
base.  For  Architect,  this  eliminated  the  need  for  the  domain-specific  grammar  and  the 
visual-system  grammar  which  were  used  to  parse  file-based  descriptions  of  domain  data 
between  the  file  system  and  the  object  base. 

We  also  found  that,  for  a  given  domain,  there  is  a  minim^d  set  of  data  reflected 
in  an  object  model  that  is  duplicated  many  times  when  the  object  model  is  flattened  to 
conform  to  a  file-bsised  format.  By  keeping  the  domain  data  encapsulated  in  one  location 
in  the  database,  we  eliminate  the  duplication  of  data,  and  we  can  better  protect  it  from 
corruption.  Changes  to  domsun  data  are  now  centralized,  and  we  are  guaranteed  that  all 
applications  accessing  the  database  are  working  with  the  same  domain  definition. 

The  OODBMS  technology  base  greatly  increeises  the  reusability  of  not  only  the 
domain-oriented  artifacts  stored  in  the  database,  but  of  the  domain  and  architecture  models 
used  to  implement  a  domain-oriented  application  composition  environment  as  well. 

The  OODBMS  environment  is  much  more  conducive  to  exploiting  the  power  offered 
by  object  modeling  and  model-based  software  development.  We  found  it  to  be  a  very 
natural  environment  in  which  to  develop  a  meta-model  for  domain  models,  enabling  us  to 
define  domains  in  an  implementation-independent  way.  By  abstracting  a  class  of  models 
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into  a  meta-model  and  implementing  that  meta-model  in  an  OODBMS  we  can  significantly 
reduce  the  effort  required  to  generate  multiple  versions  of  the  same  or  similar  data.  Our 
development  and  implementation  of  a  domain-definition  meta-model  demonstrated  this 
capability. 

6.2  Recommendations  for  Further  Research 

•  Develop  a  Meta-Model  of  Architecture  Models 

Just  as  we  developed  a  meta-model  for  a  class  of  domain  models,  a  meta-model 
describing  a  clziss  of  architectiure  models  should  be  investigated.  Architect  is  based  on 
the  OCU  architecture  model,  but  if  a  common  formal  description  of  architecture  mod¬ 
els  existed,  it  would  ease  the  transformation  of  reusable  software  Eurtifacts  between 
Eurchitectures,  thereby  improving  reusability.  Gool  (11)  conducted  some  reseEirch  into 
alternative  architectures  for  systems  like  Architect  that  might  be  helpful. 

•  Further  Abstract  the  Transformation  Methods  for  the  DomEiin-Definition  Model 

Currently  the  methods  in  the  domain-definition  meta-model  encapsulate  knowledge 
of  the  tEirget  environment.  In  the  case  of  the  methods  used  to  generate  the  database 
schema,  the  methods  encapsulate  knowledge  of  the  grammEir  for  the  ITASCA  schema- 
generation  code.  In  the  CEwe  of  the  methods  used  to  generate  the  Refinb  source  code, 
knowledge  of  the  Rbfine  progrEunming  language  is  encapsulated  in  the  methods. 
These  tramsformation  methods  may  be  further  abstrEicted  to  allow  a  formad  descrip¬ 
tion  of  the  tEirget  environment  be  Ein  input  to  the  method.  Insteaul  of  embedding 
implementation-specific  details  in  the  methods,  generalize  the  methods  to  taike  as 
input  all  the  Eiffected  models  amd  perform  the  tramsformations  based  solely  on  inputs. 
This  way,  a  new  set  of  methods  won’t  have  to  be  written  for  eswrh  environment  wishing 
to  Eiccess  reusable  Eu1;ifEM:ts  from  a  domadn. 

•  Provide  Additional  Functionaility  for  Meta-Models 

Currently,  there  aure  very  limited  syntawdiic,  semantic,  aind  consistency  checks  done 
when  the  domain-definition  meta-model  is  popidated  with  the  definition  of  a  domain. 
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Methods  could  be  written  to  perform  these  types  of  checks  for  the  Domain  and 
Software  Engineers. 

•  Investigate  using  the  OODBMS  for  a  dynamic  simulation  environment 

We  have  concentrated  on  the  static  portion  of  the  J-MASS  modeling  library  in  our 
research.  The  capability  to  execute  simulations  of  applications  in  the  OODBMS 
should  be  investigated.  Halloran  (12)  did  some  preliminary  work  in  this  area. 

•  Incorporate  Other  Domains  and  Architectures 

We  attempted  to  make  our  work  scalable  by  encapsulating  domain  and  architecture 
data  separately,  and  relating  them  through  inheritance.  The  introduction  of  more 
architectures  (11)  and  more  domains  like  the  digital  signal  processing  domeun  (34)  is 
needed  to  further  validate  these  capabilities.  As  more  domains  and  architectures 
become  available,  additional  research  opportunities  arise,  such  as  the  sharing  of 
domain  artifacts  between  domains  and  architectures. 

•  Explore  Versioning  and  Schema  Evolution  Capabilities  of  OODBMS 

The  Versioning  and  Schema  Evolution  Capabilities  offered  by  the  OODBMS  could 
be  very  benefici2J  to  both  the  end-user  Application  Specialist  working  with  different 
versions  of  domain  data,  2ind  the  Domain  and  Software  Engineers  developing  new 
architectures  euid  domain  models. 

6.3  Final  Comments 

The  domain-oriented  application  composition  environment  described  in  this  thesis  is 
a  significant  step  in  the  right  direction  toweu-d  developing  a  modeling  library  for  J-MASS. 
It  also  serves  as  a  proof  of  concept  for  some  uses  of  object-oriented  database  management 
systems  in  software  development  and  composition  systems.  It  is  no  longer  necessary  to 
corrupt  object-oriented  data  into  a  flattened  structure  in  order  to  store  it  in  a  technology 
base.  By  storing  object-oriented  data  in  its  natural  object-oriented  form,  you  maintain 
those  characteristics  that  led  you  to  use  the  object  parauligm  in  the  first  place!  With 
methods  stored  in  the  database,  new  views  of  abstract  data  only  require  the  writing  of 
a  new  method.  Once  written,  it  resides  with  the  data,  and  becomes  a  tool  available  to 
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many  users.  The  isolation  of  data  from  specific  implementations  greatly  improves  the 
productivity  of  software  engineering  professionals  as  well  as  application  specialists.  Using 
an  OODBMS  sis  the  technology  base  for  a  set  of  object-based  tools  is  a  natural  progression 
in  the  effort  to  capitalize  on  the  benefits  offered  by  the  object  paradigm. 
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Appendix  A.  Description  of  Technology  Base  Primitives  for  Logic  Circuits  Domain 

This  appendix  contains  a  brief  description  of  the  data  collection  forms  used  to  capture 
domain  knowledge  for  a  given  application  domain.  Having  the  data  in  this  form  makes  it 
easier  for  the  dom2dn  specialist  to  enter  the  data  into  the  ITASCA  OODBMS.  Section  A. 2 
htis  all  the  forms  that  were  filled  out  to  define  the  logic  circuits  domain.  Appendix  B  lists 
all  the  Refine  code  that  is  generated  from  this  data  by  the  ITASCA  database  methods. 
The  code  is  used  by  the  AVSI/ Architect  system  to  define  the  primitives  of  the  logic  circuits 
domain. 


A.l  Description  of  Data  Collection  Forms 


Figure  A.l  Data  Collection  Form  for  DOMAIN-DEF  Class 

The  contents  of  the  Name  field  on  this  form  are  used  to  name  an  application  domain.  Fig¬ 
ure  A. 9,  the  completed  DOMAIN-DEF  form  for  the  logic  circuits  domain,  has  the  value  “circuits” 
in  the  name  field.  The  corresponding  object  class  created  as  a  result  of  this  data  is  the  “circuits” 
abstract  class  near  the  top  of  Figure  4.1.  You  can  also  see  from  the  Domain-Definition  Object 
Model  illustrated  in  Figure  4.7,  that  the  DOMAIN-DEF  class  has  an  is-composed-of  relationship 
with  the  OBJECT-CLASS  class.  The  completed  DOMAIN-DEF  form  (Figure  A.9)  for  the  circuits 
domain  lists  all  the  object  classes  needed  to  define  the  logic  circuits  domain.  This  can  be  verified 
by  comparing  Figure  A.9  to  Figure  4.1.  The  description  field  is  optional  on  this  and  all  other  data 
collection  forms. 
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Figure  A. 2  Data  Collection  Form  for  OBJECT-CLASS  Class 

The  Object-Class  data  collection  form  is  used  to  describe  ail  the  object  classes  in  an  appli¬ 
cation  domain.  In  the  case  of  the  logic  circuits  dommn,  there  are  15  of  these  forms,  one  for  each 
object  class  below  “circuits”  in  Figure  4.1.  The  logic  circuits  forms  are  presented  from  Figure  A.IO 
through  Figure  A.24.  The  form  provides  for  a  way  to  identify  whether  a  class  is  abstract  or 
concrete.  The  name  field  provides  the  name  of  the  object  class.  The  superclass  field  is  used  to 
describe  the  hierarchy  depicted  in  Figure  4.1.  Note  that  the  data  collection  form  in  Figure  A.12 
which  defines  the  GATE  class,  lists  Circuit-Artifact  as  its  supercleiss.  Figure  4.1,  consequently, 
shows  Circuit- Artifact  as  the  superclass  of  the  GATE  class. 

Recall  from  the  Domain-Definition  Object  Model  in  Figure  4.7  that  an  OBJECT-CLASS  class 
has  an  is-composed-of  relationship  with  the  DATA-OBJECT  class.  The  OBJECT-CLASS  form  has 
a  place  to  identify  those  DATA-OBJECTs  that  are  part  of  this  relationship.  Each  DATA-OBJECT 
must  be  further  defined  as  an  attribute,  constant,  coefficient,  input,  or  output  using  the  legend  at 
the  bottom  of  the  form. 


Figure  A.3  Data  Collection  Form  for  OCU  Attributes 


The  OCU-ATTRIBUTES  form  provides  a  space  for  each  attribute’s  name,  its  type  (i.e., 
string,  symbol,  real,  etc),  an  initial  value,  and  an  optional  description. 


NAME 

TYPE 

INtT  VAL 

^msssmm 

Figure  A.4  Data  Collection  Form  for  OCU  Construits 

The  OCU-CONSTANTS  form  provides  a  space  for  each  attribute’s  name,  its  type  (i.e.,  string, 
symbol,  real,  etc),  an  initial  value,  and  an  optional  description. 


Figure  A. 5  Data  Collection  Form  for  OCU  CoeflBcients 

The  OCU-COEFFICIENTS  form  provides  a  space  for  each  coeflBcient’s  name,  initial  value 
and  optional  description. 


Figure  A.6  Data  Collection  Form  for  OCU  Inputs 

The  OCU-INPUTS  form  provides  a  space  for  each  input’s  name,  its  type  (i.e.,  string,  symbol, 
real,  etc),  and  its  category,  as  well  as  an  optional  description. 


A-4 


NAMt 


TVPt 


ICATCOOAV 


DMcnrrtON 


Figure  A. 7  Data  Collection  Form  for  OCU  Outputs 

The  OCU-OUTPUTS  form  provides  a  apace  for  each  output’s  name,  its  type  (i.e.,  string, 
symbol,  real,  etc),  its  category,  and  an  optional  description. 


Figure  A.8  Data  Collection  Form  for  OCU  Functions 

The  REFINE-FUNCTION  data  collection  form  provides  space  for  each  function’s  name. 
The  UPDATE  space  allows  the  domain  specialist  to  identify  whether  a  function  is  to  be  used  as  a 
function’s  update  function  or  not.  The  actual  Repine  code  can  be  written  in  the  block  provided. 


A. 2  Completed  Data  Collection  Forms  for  the  Logic  Circuits  Domain 


Figure  A.IO  Completed  Data  Collection  Form  for  Circuit-Artifact  OBJECT-CLASS 


Figure  A. 13  Completed  Data  Collection  Form  for  Switch  OBJECT-CLASS 


Figure  A. 15  Completed  Data  Collection  Form  for  And-Gate  OBJECT-CLASS 


Figure  A,16  Completed  Data  Collection  Form  for  Or-Gate  OBJECT-CLASS 
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Figure  A.17  Completed  Data  Collection  Form  for  Nand-Gate  OBJECT-CLASS 
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Figure  A. 18  Completed  Data  Collection  Form  for  Nor-Gate  OBJECT-CLASS 
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Figure  A. 19  Completed  Data  Collection  Form  for  Not-Gate  OBJECT-CLASS 


Figure  A.20  Completed  Data  Collection  Form  for  Counter  OBJECT-CLASS 
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Figvire  A.21  Completed  Data  Collection  Form  for  Multiplexer  OBJECT-CLASS 
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Figure  A.23  Completed  Data  Collection  Form  for  Decoder  OBJECT-CLASS 
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Figure  A.25  Completed  Data  Collection  Form  for  Attributes 


Figure  A.26  Completed  Data  Collection  Form  for  Constants 
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Figure  A.27  Completed  Data  Collection  Form  for  Coefficients 


Figure  A.28  Completed  Data  Collection  Form  for  OCU-Inputs 
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Figure  A.31  Completed  Data  Collection  Form  for  REFINE-FUNCTION 
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Appendix  B.  Code  Automatically  Generated  By  Itasca  Methods 

B.l  Database  Schema  Generated  By  IXASCA  Methods 

(def-clas8  CIRCUITS 
: superclasses  (OCU-PRIMITIVE  ) 

: attributes  () 

: class-attributes  ()) 

(def-class  circuit-artifact 
: superclasses  (CIRCUITS  ) 

: attributes  ( 

(manufacturer 
: domain  string 
:init  "none  specified"  ) 

) 

: class-attributes  ()) 

(def-class  gate 

'.superclasses  (circuit-artifact  ) 

: attributes  ( 

(delay 

: domain  integer 
: init  0  ) 

(mil-spec? 

: domain  T 
: init  nil  ) 

(power-level 
; domain  float 
: init  0.0  ) 

) 

; class-attributes  ()) 

(def-class  nor-gate 
: superclasses  (gate  ) 

'.attributes  ( 

) 

: class-attributes  ()) 

(def-class  nand-gate 
: superclasses  (gate  ) 

: attributes  ( 

) 

: class-attributes  ()) 

(def-class  or-gate 
: superclasses  (gate  ) 
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:attribut«s  ( 

) 

:clas8-attribut«8  ()) 

(d«f-cla88  not-gate 
: 8upercla88e8  (gate  ) 
rattributea  ( 

) 

: cla88-attribute8  ()) 

(def-cla88  and-gate 
: superclassea  (gate  ) 

: attributes  ( 

) 

: class-attributes  ()) 

(def-class  component 
: superclasses  (circuit-artifact  ) 
: attributes  ( 

(delay 

: domain  integer 
: init  0  ) 

(mil-spec? 

: domain  T 
: init  nil  ) 

(power-level 
: domain  float 
: init  0.0  ) 

) 

: class-attributes  ( } } 

(def-class  decoder 
: superclasses  (con^onent  ) 

: attributes  ( 

) 

: class-attributes  ()) 

(def-class  jk-flip-flop 
: superclasses  (con^onent  } 

: attributes  ( 

(set-up-delay 
: domain  integer 
: init  0  ) 

(hold-delay 
: domain  float 
: init  0.0  ) 


(stat* 

: domain  T 
: init  nil  ) 

) 

: claaa-attributoa  ()) 

(def-claas  half-adder 
: superclasses  (cooq>onent  ) 

: attributes  ( 

) 

:  clus-attributes  (}) 

(def-class  counter 
: superclasses  (conq>onent  ) 

: attributes  ( 

(the-count 
: domain  integer 
: init  0  ) 

) 

: class-attributes  ()) 

(def-class  mux 
: superclasses  (component  ) 

: attributes  ( 

) 

: class-attributes  (}) 

(def-class  led 

: superclasses  (circuit-artifact  } 
: attributes  ( 

(color 

: domain  symbol 
: init  red  ) 

) 

: class-attributes  ()} 

(def-class  switch 
: superclasses  (circuit-artifact  ) 
: attributes  ( 

(delay 

.'domain  integer 
: init  0  ) 

(debounced 
: domain  T 
:  init  nil  ) 


(tha-poaition 
:  domain  symbol 
: init  on  ) 

) 

: clasa-attributas  ()} 


B.2  Refine  Source  Code  Generated  By  ITASCA  Methods 

The  following  Refine  source  code  was  produced  by  the  Methods  we  developed  in  Itasca. 
This  source  file  corresponds  to  the  digital  logic  circuits  domain. 

!!  in-packaga("AVSI") 

! !  in-grammar ( ’ user) 

"This  is  the  CIRCUITS  domain" 

var  CIRCUITS  :  objact-claaa  snbtypa-of  Primitiva-Obj 

"circuit-artifact  is  the  highest  level  you  can  add  domain  specific  attributes" 
var  circuit-artifact  :  object-class  subtjrpe-of  CIRCUITS 

"superclass  for  all  elementary  circuit  items" 
var  gate  :  object-class  subtype-of  circuit-artifact 

"The  NOR  Gate  combines  its  tuo  inputs  together 
(after  the  appropriate  delay)  as  follows 


input 1  I  input2  I  output 


F  I  F  I  T 

F  1  T  1  F 

T  I  F  I  F 

T  I  T  I  F 

II 


var  nor-gate  :  object-class  subtype-of  gate 

"The  NAND  Gate  combines  its  two  inputs  together 
(after  the  appropriate  delay)  as  follows 


input 1 

input2 

1  output 

1  . 

F 

F 

[ 

1  T 

F 

T 

1  T 

T 

F 

1  T 

T 

T 

1  F 

II 

var  nand-gate  ;  object-class  subtype-of  gate 
"The  OR  Gate  combines  its  two  inputs  together 
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(aft«r  th*  appropriat*  dalay)  as  follovs 


input 1 

input2 

output 

F 

F 

F 

F 

T 

T 

T 

F 

T 

T 

T 

T 

var  or-gate  :  objsct-claas  subtyps-of  gats 

"Tbs  NOT  Gats  takas  ona  input  and  invarts  it 
(2iftar  tha  appropriata  dalay)  as  follovs 

input  I  output 

- 1 - 

F  I  T 
T  I  F 

II 

var  not-gata  :  objact-class  subtyps-of  gata 

"Tha  AND  Gata  combinas  its  tvo  inputs  togathar 
(aftar  tha  appropriata  dalay)  as  follovs 


input 1 

input2  1 

output 

F 

F  1 

F 

F 

T  1 

F 

T 

F  1 

F 

T 

T  1 

T 

var  and-gata  :  objact-class  subtypa-of  gata 

"suparclass  for  all  coiq)osita  itams  in  circuits  domain" 
var  consonant  :  objact-class  subtypa-of  circuit-artifact 

"description  for  dacodar" 

var  decoder  :  oVj act-class  subtypa-of  component 
"description  for  jk-flip-flop" 

var  jk-flip-flop  :  object -c^aas  subtypa-of  consonant 
"description  for  half-adder" 

var  half -adder  :  objact-class  subtypa-of  coiq>onant 

"description  for  description  for  counter" 
vu  cotmtar  :  objact-class  subtypa-of  cooiponant 

"description  for  muz" 

var  muz  :  objact-class  subtypa-of  component 
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"dascriptioB  for  lod" 

vax  lad  :  objact-claas  aubtypa-of  circuit-artifact 


"dascriptioa  for  avitch" 

var  avitch  :  objact-claaa  aubtypa-of  circuit-artifact 
var  nor-gata-input-data  :  aat(iiq>ort-obj)  ■  { 


aat-attra  (maka-objact  (’ioport-obj), 
>  ioport-nama ,  *  ini , 

> io^ort-catagory ,  ’ aignal , 
>iiq>ort-typa-data,  ’boolaan). 


aat-attra  (maka-objact  ( ’ in^ort-obj ) , 

' in^ort-nama ,  * in2 , 

>i]ig)ort-catagory,  ’aignal, 
’iiq>ort-typa-data,  *boolaan)> 

var  nor-gata-output-data  :  aat(axport-obj)  ■  { 


aat-attra  (maka-objact  (*arport-obj), 

’azport-nama,  ’outl, 

’axport-catagory,  ’aignal, 

’axport-typa-data,  ’boolaan)} 

var  nor-gata-coafficianta  :  map(nor-gata,  aat(nama-valua-obj)) 
coo^utad-uaing 

nor-gata-coafficianta (x)  »  <} 

form  MAKE-nor-gata-NAMES-UNIQUE 

uniqua-namaa-clua(’nor-gata,  trua) 

"gata  (abatract-claaa)  1" 
var  nor-gata-dalay  :  map(nor-gata,  intagar) 
con^utad-uaing 

nor-gata-dalay(x)  =  0 

"gata  (abatract-claaa)  2" 

var  nor-gata-mil-apac?  :  map(nor-gata,  boolaan) 
computad-uaing 

nor-gata-mil-apac?(x)  »  nil 

"gata  (abatract-claaa)  3" 

var  nor-gata-povar-laval  :  map(nor-gata,  raal) 
coiiq>utad-uaing 

nor-gata-povar-laval (x)  *  0.0 

"Thia  ia  tha  nama  of  tha  cosg>any  that  manufacturad  tha  gata" 
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'none  specified' 


vnr  nor-gnte-aanufactnrer  :  map(nor-gate.  string) 
coBg>uted-asing 

nor-gate-nanafactiirsr(z)  >  " 

function  MQR-GiTE-UPDiTEl  (subsystea  :  subsystea-ob j , 

nor-gate  :  H0R-6iTE)  » 

foraat (debug-on,  "MOR-GlTE-OBJ-OPDATEi  on  *s'X".  name (nor-gate) ) ; 

let  (ini  :  boolean  *  get-laport(*inl,  subsystem,  nor-gate), 
in2  :  boolean  =  get-i]q>ort(*in2,  subsystem,  nor-gate)) 

set-export(subsystem,  nor-gate,  *outl,  '(ini  or  in2)) 

function  N0R-G1TE-UPDATE2  (subsystem  :  subsystem-obj , 

nor-gate  :  NOR-GATE)  * 

format(t,  "NOR-GATE-OBJ-OPDATE2  on  "s'X”,  name (nor-gate)) 

var  nor-gate-update-f unction  ;  map (nor-gate,  symbol) 

conputed-using 

nor-gate-update-function(z)  =  ’HOR-GATE-DPDATEl 

var  decoder- input-data  :  set(import-obj)  =  i 

set-attrs  (make-object  ( ’ in5)ort-obj ) , 

* import-name ,  ' ini , 

’iiport-category,  ’signal, 

’import-type-data,  ’boolean), 

set-attrs  (m2dce-object  (’in^ort-obj) , 

’ isport-name ,  ’ in2 , 

’U9>ort-category,  ’signal, 

’import-type-data,  ’boolean), 

set-attrs  (make-object  (’iiiq)ort-obj) , 

’  iiq>ort-name ,  ’ln3, 

’in^ort-category,  ’signal, 

’import-type-data,  ’boolean)} 

var  decoder-output -data  :  set(ezport-obj)  =  { 

set-attrs  (make-object  (’ezport-obj) , 

’ezport-name,  ’mO, 

’ezport-category,  ’signal. 
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’•xport-typ«-dmta,  ’boolaaa) 


s«t-attr8  (iiiak«-obj«ct  (*«xport-obj) . 
’ •zport-naiM ,  *ml , 
’•zport-catagory,  ’signal, 
’•xport-typa-data,  ’boolaan). 


sst-attrs  (naks-objact  (*axport-obj), 
’szport-naas,  ’m2, 
’szport-eatagoxy,  ’signal, 

’ sxport-typs-data ,  ’boolean) , 


sst-attrs  (maks-objsct  (’ export -obj), 
’export-name,  ’m3, 
’export-category,  ’signal, 
’export-type-data,  ’boolean). 


set-attrs  (make-object  (’export-obj) , 
’ export-name ,  ’m4 , 
’export-category,  ’signal, 
’export-type-data,  ’boolean). 


set-attrs  (make-object  (’export-obj), 
’export-name,  ’mS, 
’export-category,  ’signal, 
’export-type-data,  ’boolean), 

set-attrs  (make-object  (’export-obj), 
’export-name,  ’m6, 
’export-category,  ’signal, 

’ export-type-data ,  ’boolean) , 


set-attrs  (make-object  (’export-obj), 

’ export-name ,  ’m7 , 

’export-category,  ’signal, 

’export-type-data,  ’boolean)} 

var  decoder-coefficients  :  map(decoder,  8et(name-valae-obj)) 
co]q>uted-u8ing 

decoder-coefficient8(x)  =  <} 

form  HAKE-decoder-NAMES-UHiqUE 

uniqae-name8-class( ’decoder ,  tme) 
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"This  is  the  daisy  (in  nanosaconds)  batwaan  tha  tiina  tha  gsta 
racaivas  it’s  input (s)  and  tha  tisia  tha  output  is  availabla" 
var  dacodar-dalay  :  mapCdacodax,  intagar) 
conputad-using 

dacodar-dalay(z)  »  0 

"A  trua  valua  maans  tha  gata  maats  azacting  military  spacifications 
A  falsa  valua  maans  tha  gata  only  maats  IEEE  spacifications" 
var  dacodor-mil-si>ac?  :  mapCdacodar.  boolaan) 
coaqmtad-using 

dacodar-mil-spac?(z)  «  nil 

"consonant  (abstract-class)  3" 
var  dacodar-povar-laval  :  map(dacodar,  raal) 
cooqputad-using 

dacodar-pouar-laval(x)  =  0.0 

"This  is  tha  nama  of  tha  coiq>any  that  manufacturad  tha  gata" 
var  dacodar-manufacturar  :  map(dacodar,  string) 
computad-using 

dacodar-manufacturar(z)  «  "nona  spacifiad" 

function  OECODER-UPDATEl  (subsystam  :  subsystam-ob j , 

dacodar  :  DECODER)  = 

lat  (z  :  boolaan  gat-ifflport(’ini,  subsystam,  dacodar), 

y  ;  boolaan  gat-iiiport(*in2,  subsystam,  dacodar), 

z  :  boolaan  -  gat-import (’in3,  subsystam,  dacodar)) 

%  sat  all  outputs  to  falsa  to  start;  don't  want  uy  laft-ovar 
%  valuas  advarsaly  aff acting  output. 

sat-azport (subsystam,  dacodar,  *m0,  nil); 
sat-azport (subsystam,  dacodar,  ’ml,  nil); 
sat-axport(subsystam,  dacodar,  'm2,  nil); 
sat-azport (subsystam,  dacodar,  'm3,  nil); 
sat-azport (subsystam,  dacodar,  ’m4,  nil); 
sat-azport (subsystam,  dacodar,  ’m5,  nil); 
sat-azport (subsystam,  dacodar,  ’m6,  nil); 
sat-azport (subsystam,  dacodar,  'm7,  nil); 

if  *z  and  'y  and  ~z  than 

sat-azport (subsystam,  dacodar,  'mO,  trua) 
alsaif  *z  and  'y  and  z  than 

sat-azport(8ubsystam,  dacodar,  'ml,  trua) 
alsaif  *z  and  y  and  'z  than 

sat-azport (subsystam,  dacodar,  ’m2,  trua) 
alsaif  'z  and  y  and  z  than 

sat-azport (subsystam,  dacodar,  ’m3,  trua) 
alsaif  z  and  'y  and  'z  than 

8at-azport(8ub8ystam,  dacodar,  ’m4,  trua) 
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z  and  "j  and  z  than 

aet-axportCaubaystam,  dacodar,  *m5,  trna) 
alaaif  z  and  y  and  'z  than 

aat-azportCaubayatam,  dacodar,  ’m6,  trua) 
alaaif  z  and  y  and  z  than 
aat-azportCaubayatam,  dacodar,  ’m7,  trua) 

var  dacodar-updata-function  :  map<dacodar,  aymbol) 
conputad-uaing 

dacodar-updata-function(z)  »  ’DECODER-DPDATEl 
var  nand-gata-input-data  :  aat(inport-obj)  «  { 


aat-attra  (maka-objact  ('iiq>ort-obj) , 
* import-naDa ,  ’ ini , 
'import-catagory,  ’aignal, 

’ import -typa-data,  ’boolaan) , 


aat-attra  (nudca-objact  (’iaport-obj) , 

> in^ort-nama ,  ’ in2 , 

* inport-catagory ,  'aignal, 
’inport-typa-data,  ’boolaan)} 

var  nand-gata-otttput-data  ;  aat<azport-obj)  *  { 


aat-attra  (maka-objact  (’azport-obj) , 

’ axport-nama ,  ’ outl , 

’azport-catagory,  ’aignal, 

’azport-typa-data,  ’boolaan)} 

var  nand-gata-coafficianta  :  map(nand-gata,  aat(nama-v2tlua-obj)) 
conputad-naing 

nand-gata-coafficianta (x)  =  {} 

form  NAKE-nand-gata-NANES-UNiqUE 

uniqiia-namaa-claaa(’nand-gata,  trua) 

"gata  (abatract-claaa)  1" 

var  nand-gata-dalay  :  map(nand-gata,  intagar) 
coo^tad-uaing 

nand-gata-dalay(x)  =  0 

"gata  (abatract-claaa)  2" 

var  nand-gate-mil-spac?  :  map(nand-gata,  boolaan) 
conputad-uaing 

nand-gata-mil-8pac?(x)  =  nil 
"gate  (abatract-claaa)  3" 
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var  nand-gata-power-laval  :  au^Cnand-gata,  raal) 
conqputed-using 

nand-gata-povar-laval(x)  *  0.0 

"This  is  the  nasw  of  the  coiq>any  that  manufactured  the  gate" 
var  nand-gate-manufacturer  :  map(nand-gate,  string) 
conputed-using 

nand-gate-inanufacturer(z)  »  “none  specified" 

function  NAND-GATE-UPDATEl  (subsystem  :  subsystem-obj . 

nand-gate  :  HAND-GATE)  * 

format (debug-on,  "MAND-GATE-OBJ-UPDATEl  on  "s'X",  name (nand-gate) ) ; 

let  (ini  :  boolean  =  get-inportCinl,  subsystem,  nand-gate), 
in2  :  boolean  -  get-i]iport(*in2,  subsystem,  nand-gate)) 

set-export (subsystem,  nand-gate,  ’outl,  '(ini  A  in2)) 


function  NAND-GATE-DPDATE2  (subsystem  :  subsystem-obj , 

nand-gate  :  NAND-GATE)  - 

format (t,  "NAND-GATE-OBJ-NEH-UPDATE  on  's'X",  name (nand-gate)) 

var  nand-gate-update-lunction  :  map(nand-gnte ,  symbol) 
computed-using 

nand-gate-update-function(x)  =  ’NAND-GATE-OPDATEl 
var  or-gate-input-data  :  set(i]iport-obj)  =  { 


set-attrs  (make-object  (’inport-obj), 
’ import-name ,  ’ ini , 
’import-category,  ’signal, 
’import-type-data,  ’boolean). 


set-attrs  (make-object  (’ import -obj), 

’ import-name ,  ’ in2 , 
’import-category,  ’signal, 
’import-type-data,  ’boolean)} 

var  or-gate-output-data  :  set(export-obj)  =  ■{ 


set-attrs  (make-object  (’export-obj) , 
’ export-name ,  ’ outl , 
’export-category,  ’signal, 
’export-type-data,  ’boolean)} 
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var  OT-gata-coeflicianta  :  mapCor-gata,  aatCnasa-Talua-obj)) 
compatad-using 

or-gata-coafficiantaCx)  ■  {} 

form  MAKE-or-gata-NANES-UMiqUE 

uniqua-namas-clasaC’or-gata,  trua) 

"gata  (abatract-cleuia}  1" 
var  or-gata-dalay  :  map(or-gata,  intagar) 
conq>iitad-U8ing 

or-gata-dalayCz)  =  0 

"gata  (abstract-class)  2" 

var  or-gata-mil-spac?  :  map(or-gata,  boolean) 
computad-using 

or-gata-mil-spac? (x)  =  nil 

"gata  (abstract-class)  3" 
var  or-gate-povar-laval  :  map(or-gata,  real) 
cooq)atad-using 

or-gata-powar-leval(x)  =0.0 

"This  is  tha  nama  of  tha  conq>any  that  manufactnrad  the  gata" 
var  or-gata-manufacturar  :  map(or-gata,  string) 
conq>utad-asing 

or-gata-man\ifactnxax(x)  *  "none  spacifiad" 

function  0R-6ATE-UP0iTEl  (subsystam  :  subsystam-ob j , 

or-gata  :  OR-GATE)  = 

format (dabug-on,  "OR-GATE-OBJ-UPDATEl  on  's'X",  name(or-gate)) ; 

let  (ini  :  boolean  =  gat-iitq>ort(’inl,  subsystem,  or-gata), 
in2  :  boolean  =  gat-iiiq>ort(’in2,  subsystam,  or-gata)) 

sat-export (subsystam,  or-gata,  ’outl,  (ini  or  in2)) 


function  0R-GATE-UPDATE2  (subsystam  :  subsystam-obj , 

or-gata  :  OR-GATE)  = 

format(t,  "OR-GATE-OBJ-OPDATE2  on  "s'X",  nama (or-gata)) 

var  or-gata-updata-function  :  map(or-gata,  symbol) 
computad-using 

or-gata-updata-function(x)  =  ’OR-GATE-DPDATEl 
var  Isd-input-data  :  sat(ifflport-obj)  =  •( 


sat-attrs  (maka-objact  (’ioport-obj). 
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’import-nam«,  ’ini, 

’ import-category ,  ’ signal , 

’in5)ort-type-data,  ’boolean)} 

var  led-output-data  :  set ( export -obj)  =  { 

> 

var  led-coeff  icients  :  mapded,  set  (name -vailue-obj)) 
computed-using 

led-coefficients(x)  =  O 

form  MAKE-led-NAMES-UNIQUE 

unique-names-classC’led,  true) 

"led  1" 

veu:  led-color  :  mapCled,  symbol) 
computed-using 

led-color (x)  =  ’red 

"This  is  the  name  of  the  company  that  manufactured  the  gate” 
var  led-manufacturar  :  mapded,  string) 
con^>uted-using 

led-manufacturer(x)  =  "none  specified" 

function  LED-ON-OFF-UPDATE  (subsystem  :  subsystem-obj , 

led  :  LED)  » 

format (debug-on,  "LED-OBJ-ON-OFF-UPDATE  on  's'X",  name(led)); 

let  (display-value  :  symbol  =  ’off) 

(if  get-import (’ini,  subsystem,  led)  then 
display-value  <-  ’on 

): 

format(true,  "LED  *8  =  's"%",  nameded),  display- value) 


function  LED-T-F-UPDATE  (subsystem  :  subsystem-obj, 

led  :  LED)  = 

format (debug-on,  "LED-OBJ-T-F-OPDATE  on  "s'X",  name(led)); 

let  (display-value  :  symbol  =  ’false) 

(if  get-import(’inl,  subsystem,  led)  then 
display-value  <-  ’true 

); 

format(true,  "LED  "s  =  's'%",  nameded),  display- value) 

var  led-update-f unction  :  mapded,  symbol) 
computed-using 
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led-update-fiuiction(z)  =  ’LED-ON-OFF-UPDATE 


jk-f lip-flop-input-data  :  aetCin^jort-obj)  =  { 


aet-attrs  (make-objact  ( ' in^ort-ob j ) , 
’ import-nano ,  ’ j , 
’import-category,  ’signal, 
’import-type-data,  ’boolean). 


set-attrs  (make-object  ( ’import -obj) , 
’ import -name ,  ’ k , 
’import-category,  ’signal, 

’ import-type-data,  ’boolean) , 


set-attrs  (make-object  (’import -obj), 
’import-name,  ’elk, 

’import-category,  ’signal, 

’import -type-data,  ’boolean)} 

var  jk-f lip-flop-output-data  :  aot(export-obj)  =  { 


set-attrs  (make-object  (’export-obj) , 

’export -name,  ’q, 

’export-category,  ’signal, 

’export-type-data,  ’boolean), 

set-attrs  (make-object  ( ’ export-ob j ) , 

’export-name,  ’q-bar, 

’export-category,  ’signal, 

’export -typo -data,  ’boolean)} 

var  jk-flip-flop-coefficients  :  map(jk-flip-flop,  8et(name-vedue-obj)) 
computed-using 

jk-flip-flop-coefficients(x)  =  O 

form  MAKE-jk-flip-flop-NAMES-UNiqOE 

unique-names-class( ’jk-f lip-flop ,  true) 

"jk-f lip-flop  1" 

var  jk-f lip-flop-set-up-delay  :  map( jk-f lip-flop,  integer) 
c  oiiq>ut  e  d-us  ing 

jk-flip-flop-set-up-delay(x)  =  0 

"jk-flip-flop  2" 

var  jk-f lip-flop-hold-delay  :  map (jk-flip-flop,  real) 
coiiq>uted-us  ing 


jk-flip-f lop-hold-delay (x)  *  0.0 


"jk-llip-llop  3" 

var  jk-flip-flop-etate  :  map(jk-flip-flop,  boolean) 
computed-uaing 

jk-flip-flop-state(x)  =  nil 

"This  is  the  delay  (in  nanoseconds)  between  the  time  the  gate 
receives  it’s  input (s)  and  the  time  the  output  is  available" 
var  jk-flip-f lop-delay  :  map( jk-flip-f lop,  integer) 
con^uted-using 

jk-flip-flop-delay(x)  =  0 

"A  true  value  means  the  gate  meets  exacting  military  specifications 
A  false  value  means  the  gate  only  meets  IEEE  specifications" 
var  jk-flip-flop-mil-spec?  :  map (jk-flip-f lop,  boolean) 
computed-using 

jk-flip-flop-mil-8pec?(x)  =  nil 
"consonant  (abstract-class)  3" 

var  jk-flip-flop-power-level  :  map(jk-flip-flop,  real) 
computed-using 

jk-flip-f lop-power-level(x)  =0.0 


"This  is  the  name  of  the  company  that  manufactured  the  gate" 
var  jk-flip-flop-manufacturer  *.  map(jk-f lip-flop,  string) 
computed-using 

jk-flip-flop-manufacturer(x)  =  "none  specified" 

function  JK-FLIP-FLOP-OPDATEl  (subsystem  :  subsystem-obj , 

jk-flip-flop  :  JK-FLIP-FLOP)  = 

format  (debug-on,  "JK-FLIP-FLOP-OPDATEl  on  "s"/,",  name(  jk-flip-flop)) ; 


lot  (j  :  boolean  =  get-import(’ J,  subsystem,  jk-flip-flop), 

k  :  boolean  =  get-uq>ort(’K,  subsystem,  jk-flip-flop), 

elk  :  boolean  =  get-iaport(*Clk,  subsystem,  jk-flip-flop)) 


(if  'j  A  k  A  elk  then 

JK-FLIP-FLOP-STATE(jk-flip-flop)  <-  nil 

elseif  j  A  k  A  elk  then 

JK-FLIP-FLOP-STATE(jk-flip-flop)  <-  'JK-FLIP-FLOP-STATE( jk-flip-flop) 

elseif  j  A  'k  and  elk  then 

JK-FLIP-FLOP-STATE(jk-flip-flop)  <-  true 

); 


set-export(subsystem,  jk-flip-flop,  ’Q,  JK-FLIP-FLOP-STATE( jk-flip-f lop) ) ; 
set-export (subsystem,  jk-flip-flop,  ’Q-Bar,  ■’JK-FLIP-FLOP-STATE(jk-flip-flop)) 
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function  JK-FLIP-FL0P-UPDATE2  (subsystom  ;  Kubnyttom-ob j , 

jk-flip-flop  :  JK-FLIP-FLOP)  » 

format (t,  "JK-FLIP-FL0P-UPDATE2  on  'a'X",  nan* (jk-flip-flop)) 

var  jk-flip-flop-updata-f unction  :  map( jk-flip-flop,  symbol) 
conputed-using 

jk-flip-flop-updata-function(x)  =  ' JK-FLIP-FLOP-UPDATEl 
var  half-addar-input-data  :  8et(inport-obj)  *  •{ 


set-attrs  (mak«-objsct  (* import -obj) , 
'isport-nama,  ’ini, 
’import-catagory,  ’signal, 

’ inport -typa-data,  ’boolaan). 


sat-attrs  (maka-objact  (’import-obj), 

’ import -nama,  ’in2, 

’inport-catagory,  ’signal, 
’import-typa-data,  ’boolaan)} 

var  half-addar-output-data  :  sat (axport-obj )  *  { 


sat-attrs  (maka-objact  (’axport-obj), 
’ axport-nama ,  ’ s , 
’axport-catagory,  ’signal, 
’axport-typa-data,  ’boolaan). 


sat-attrs  (maka-objact  (’axport-obj), 

’axport-nama,  ’c, 

’axport-catagory,  ’signal, 

’axport-typa-data,  ’boolaan)} 

var  balf-addar-coafficiants  :  map (half -addar,  sat(nama-valua-obj)) 
computad-using 

half-addar-coafficiants(x)  =  {} 

form  MAKE-half-addar-NAMES-UNIQUE 

uniqua-namas-class ( ’ half -addar ,  trua) 

"This  is  tha  dalay  (in  nanosaconds)  batvaan  tha  tima  tha  gata 
racaivas  it’s  input(s)  and  tha  tima  tha  output  is  availabla" 
var  half-addar-dalay  :  map (half -addar,  intagar) 
conputad-using 

half-addar-dalay(x)  =  0 
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"A  true  value  means  the  gate  meets  exacting  military  specifications 
A  false  value  means  the  gate  only  meets  IEEE  specifications'* 
var  half-adder-mil-spec?  :  map (half -adder,  boolean) 
computed-using 

half -adder-mil-spec? (z)  »  nil 
"component  (abstract-class)  3" 

var  half-adder-pover-level  :  map (half -adder,  real) 
conputed-using 

half-adder-power-level(x)  =0.0 

"This  is  the  name  of  the  conpany  that  manufactured  the  gate" 
var  half-adder-manufacturer  :  map (half -adder,  string) 
computed-using 

half-adder-mannfacturer(z)  =  "none  specified" 

function  HALF-AODER-UPDATEl  (subsystem  :  subsystem-obj , 

half-adder  :  HALF-ADDER)  = 


let  (ini  ;  boolean  =  get-i]iport(’inl,  subsystem,  half-adder), 
in2  :  boolean  =  get-import (’in2,  subsystem,  half-adder)) 


if  'ini  and  'in2  then 

set-export (subsystem,  half-adder, 
set-export (subsystem,  half -adder, 
elseif  ini  and  'in2  then 

set-export (subsystem,  half-adder, 
set-export (subsystem,  half-adder, 
elseif  'ini  and  in2  then 

set-export ( subsystem ,  half -adder , 
set-export (subsystem,  half-adder, 
elseif  ini  and  in2  then 

set-export (subsystem,  half-adder, 
set-export(sub8ystem,  half-adder. 


'8,  nil); 
'c,  nil) 

*8,  true); 
»c,  nil) 

’s,  true); 
’c,  nil) 

’s,  nil); 
’c,  true) 


var  half-adder-update-f unction  :  map (half -adder,  symbol) 
cooputed-using 

h2G.f-adder-update-function(x)  =  ’HALF-ADDER-UPDATEl 


var  counter-input-data  ;  setdoport-obj)  =  i 


set-attrs  (make-object  (’iaport-obj) , 
'import-name,  ’clock, 
’inport-category,  ’signal, 
’inport-t3rpe-data,  ’boolean). 


set-attrs  (make-object  (’import-obj) , 
’ inport-name ,  ’ reset , 
’inport-category,  ’signal. 
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’  iiq>ort-typ«-data ,  ’ boolaaa) > 


var  coiintar-output-data  :  aatCazport-obj)  ■  { 


sat-attrs  (naka-objact  (*azport-obj) . 
’ azport-nama ,  ' lab , 
’axport-catagory,  'aignal, 
’axport-typa-data,  'boolaan). 


aat-attra  (maka-objact  (*axport-obj), 

* azport-nama,  ’mab, 

* axport-catagory,  ’aignal, 

’axport-typa-data,  ’boolaan)} 

var  conntar-coafficianta  :  mapCcountar,  8at(nama-valua-obj)) 
computad-uaing 

countar-coafficianta(x)  =  { 
aat-attra  (maka-objact  (’nama-valua-obj) , 

’nama-valua-nama,  ’max-connt, 

’nama-v2dua-valua ,  3)} 

form  NAKE-countar-NAMES-UNIQUE 

uniqua-namaa-claaa< ’ countar ,  trua) 

"countar  1" 

var  countar-tha-count  :  mapCcountar,  intagar) 
coiq>utad-uaing 

countar-tha-count (x)  =  0 

"Thia  ia  tha  dalay  (in  nanoaaconda)  batvaan  tha  tima  tba  gata 
racaivaa  it ’a  input (a)  and  tha  tima  tha  output  ia  availabla" 
var  countar-dalay  :  mapCcountar,  intagar) 
coD^utad-uaing 

countar-dalay(x)  ^  0 

"A  trua  valua  maana  tha  gata  maata  axacting  military  apacificationa 
A  falaa  valua  maana  tha  gata  only  maata  IEEE  apacificationa" 
var  countar-mil-apac?  :  mapCcountar,  boolaan) 
c  omputad-uaing 

countar-mil-apac?(x)  =  nil 

"coiiq>onant  (abatract-claaa)  3" 
var  countar-povar-laval  :  mapCcountar,  raal) 
conputad-uaing 

countar-povar-lavalCx)  «  0.0 

"Thia  ia  tha  nama  of  tha  cotopany  that  manufacturad  tha  gata" 
var  countar-manufacturar  :  mapCcountar,  atring) 
cooqputad-uaing 
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cou&t«r-maiiafactuT«r(z)  «  "none  specified' 


function  COUNTER-UPDATEl  (subsystem  :  subsysten-obj , 

counter  :  COUNTER)  * 

format (debug-on,  "COUNTER-UPDATEl  on  's'X",  name (counter) ) ; 

let  (clock  :  boolean  >  get-i]q>ort( ’clock,  subsystem,  counter), 
reset  :  boolean  >  get-i]q>ort( ’reset,  subsystem,  counter)) 

(if  reset  then 

COUNTER-THE-COUNT(counter)  <-  0 
elseif  clock  then 

COUNTER-THE-COUNT( counter)  <-  COUNTER-THE-COUNT( counter)  +1 

): 

(if  COUNTER-THE-COUNT(counter)  > 

get-coefficient-value(counter,  ’max-count)  then 
COUNTER-THE-COUNT(counter)  <-  0 

): 

if  COUNTER-THE-COUNT(counter)  =  0  then 
set-export (subsystem,  counter,  ’msb,  nil); 
set-export (subsystem,  counter,  ’Isb,  nil) 
elseif  COUNTER-THE-COUNT(counter)  =  1  then 
set-export(subsystem,  counter,  ’msb,  nil); 
set-ezport(subsystem,  counter,  ’Isb,  true) 
elseif  CQUNTER-THE-COUllT(counter)  *  2  then 
set-export (subsystem,  counter,  ’msb,  true); 
set-export (subsystem,  counter,  ’Isb,  nil) 
elseif  COUNTER-THE-COUNT(counter)  «  3  then 
set-export(subsystem,  counter,  ’msb,  true); 
set-export (subsystem,  counter,  ’Isb,  true) 

var  counter-update-function  :  map(counter,  symbol) 
conputed-using 

counter-update-function(x)  =  ’COUNTER-UPDATEl 
vax  not-gate-input-data  :  setdoport-obj)  =  { 


set-attrs  (make-object  ( ’ ioport-ob j ) , 

’  inport-name ,  ’  ini , 

’isport-category,  ’signal, 

’inport -type-data,  ’boolean)} 

var  not -gate-output-data  :  set(export-obj)  ®  ■{ 


set-attrs  (make-object  (’export-obj), 
’ export-name ,  ’ out 1 , 
’export-category,  ’signal, 
’export-type-data,  ’boolean)} 
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var  not-gatc-coafficianti  :  m^(not-gat«,  sat(naBW-Taltta-obj}} 
cooputad-ttslng 

not-gata-coafficiants(z)  »  <> 

form  NAKE-not-gata-MAMES-UHiqOE 

uniqaa-namaa-claaa ( ’not-gata ,  trua) 

"gata  (abatract-claaa)  1" 
var  not-gata-dalay  :  map(not-gata,  intagar) 
cooputad-using 

not-gata-dalay(z)  *  0 

"gata  (abstract-class)  2" 

var  not-gata-mil-spac?  :  mapCnot-gata,  boolaan) 
cosputad-usiag 

not-gata-mll-spact(z)  =  nil 

"gata  (abstract-class)  3" 

var  not-gata-povar-laval  :  map(not-gata.  raal) 
conputad-using 

not-gata-posar-laval(z)  =0.0 

"This  is  tha  nama  of  tha  company  that  manufacturad  tha  gata" 
var  not-gata-manufacttirar  :  map(not-gata,  string) 
compntad-nsing 

not-gata-manufacturar(z)  =  "nona  spacifiad" 

function  NOT-GATE-UPDATEl  (subsystam  :  subsystam-obj , 

not-gata  :  HOT-GATE)  = 

format (dabug-on,  "NOT-GATE-OBJ-DPDATEl  on  "s'X",  nama (not-gata) ) ; 
lat  (ini  :  boolaan  =  gat-import ('ini,  subsystam,  not-gata)) 
sat-azport( subsystam,  not-gata,  *outl,  '(ini)) 


function  N0T-GATE-UPDATE2  (subsystam  :  subsystam-obj, 

not-gata  :  NOT-GATE)  = 

format (t,  "M0T-GATE-0BJ-0PDATE2  on  "s'X",  nama (not-gata)) 

var  not-gata-updata-function  :  fflap(not-gata,  symbol) 
computad-using 

not-gata-updata-function(z)  =  'NOT-GATE-OPDATEl 
var  muz-input-data  :  sat(import-obj)  =  { 


sat-attrs  (maka-objact  ('inport-obj) , 
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’inqport-naiM,  'inO, 
'isqtoxt-category,  ’signal, 
’iaqport-typs-data,  ’boolsan). 


sst-attra  (maka-objact  (’loport-obj) , 
’  inport-naaa ,  ’  Inl , 
'is^ort-catagory,  'signal, 
'in^ort-typa-data,  ’boolaan). 


sat-attrs  (naka-objact  (*iiig>ort-obj) , 
’ inport -nama ,  *in2, 
'inport-catagory,  'signal, 
’inport-typa-data,  'boolaan). 


sat-attrs  (maka-objact  ('iiport-obj), 
' import-nama ,  *in3, 
'inport-catagory,  'signal, 
'inport-typa-data,  'boolaan). 


sat-attrs  (maka-objact  (’ inport -obj), 
’inport-nama,  'si, 

> inport-catagory,  'signal, 
'inport-typa-data,  'boolaan)} 

var  mux-output -data  :  sat(axport-obj)  *  ■{ 


sat-attrs  (maka-objact  ('axport-obj), 

'axport-nama,  'outl, 

'axport-catagory,  'signal, 

'axport-typa-data,  'boolaan)} 

var  mux-coafficiants  :  map(mux,  sat(nama-valua-obj)) 
conputad-using 

niux-coafficiants(x)  »  O 

form  NAKE-nmx-NAMES-UNiqUE 

uniqua-namas-class('amx,  trua) 

"This  is  tha  daisy  (in  nanosaconds)  batvaan  tha  tima  tha  gata 
racaivas  it's  input (s)  and  tha  tima  tha  output  is  av^d.labla" 
var  mux-dalay  :  map (mux,  intagar) 
conputad-using 

mux-dalay(x)  *  0 

"A  trua  valua  maans  tha  gata  maats  axacting  military  spacifications 
A  falsa  valua  maans  tha  gata  only  maats  IEEE  spacifications" 
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▼•r  anz-ail-ap^c?  :  aapCaBz,  boolaaa) 
co^utad-uaiag 

■oz-ail-sp«c?(z)  ■  nil 

"coaponant  (abstract-claiss)  3" 

▼ar  amz-povar-laval  :  aapCnz,  raal) 
coB^tad-osing 

anz-po«ar-laval(z)  «  0.0 

"Tliia  ia  tha  naoM  of  tha  coapany  tliat  manofactorad  tha  gata" 
▼ar  Buz^aaniifactiirar  :  au^Canz,  atring) 
eoa^tad-oaiag 

aoz-aanafactararCz)  »  "nona  apacifiad" 

function  MUX-OPDATEl  (aubayatan  :  aubayataa-obj , 

max  :  NDZ)  > 

lat  (aO  :  boolaan  *  gat-iaportCaO.  aubayatan,  nuz), 
al  :  boolaan  >  gat-iaport(*al.  aubayatan,  anz>) 


if  'aO  and  'al  than 
aat-azportCaubayatan,  nuz,  ’outl, 

gat-i]q>ort('inO,  aubayatan,  nuz)) 


alaaif  aO  and  'al  than 
aat>azport( aubayatan,  nuz,  *outl, 

gat-i]q>ort(’inl,  aubayatan,  amz)) 


alaaif  'aO  and  al  than 

aat-azport(aubayatan,  muz,  ’outl, 

gat-i]q>ort(’in2,  aubayatan,  muz}) 


alaaif  aO  and  al  than 

aat-azport (aubayatan,  muz,  'outl, 

gat-iaportC'inS,  aubayatan,  nuz)) 

▼ar  mnz-updata-f unction  :  n.q>(nnz,  aymbol) 
conputad-uaing 

Bniz-updata-function(z)  «  ’NDX-UPDATEl 

▼ar  avitch-input-data  :  aatCiaport-obj)  «  { 

> 

▼ar  avitch-output-data  :  aat(azport-obj)  »  { 


aat-attra  (maka-objact  (*azport~obj) , 
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'  •xport-naiM ,  *  outl , 
’•zport-catagory,  ’signal, 
’azport-t3fpa-data,  ’boolean)} 


var  svitcb-coafficiants  :  mapCavitch,  satCnaae-valna-obj)) 
cooputod-uaing 

8vitch-coafficl«nts(x)  >  {} 

form  NAKE-avitch-NAMES-DNIQUE 

unique-namea-claasC’avitcb,  true) 

"switch  1" 

var  switch-delay  :  mapCswltch,  integer) 
computed-using 

awitch-delay(z)  ^  0 


"switch  2" 

var  switch-debounced  :  map(switch,  boolean) 
conputed-uslng 

switch-debounced(x)  *  nil 


"switch  3" 

var  switch-the-position  :  mapCswitch,  a3rnibol) 
conputed-ttsing 

8witch-the-position(z)  ®  ’on 

"This  is  the  name  of  the  company  that  manufactured  the  gate" 
var  switch-manufacturer  :  mapCswitch,  string) 
cooq>uted-U8ing 

switch-manufacturerCx)  *  "none  specified" 

function  SWITCH-UPDATE  (subsystem  :  subsystem-ob j , 

switch  :  SWITCH)  » 

format (debug-on,  "SWITCH-UPDATE  on  's'X",  nameCswitch)) ; 

let  (signal  :  boolean  >  false) 

(if  SWITCH-THE-P0SITI0H(8witch)  =  ’ON  then 
signid.  <-  true 

); 


formatCt,  "Switch  'S  position  «  's'X",  name(switch) .SWITCH-THE-POSITIONCswitch)) ; 
set-export (subsystem,  switch,  ’outl,  signal) 


function  SWITCH-NEW-UPDATE  (subsystem  :  subsystem-ob j , 

switch  :  SWITCH)  = 
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fozaatCt.  "SWITCH-IIEW-UPDATE  on  '8'%".  naM(svitcli)) 


var  svitch-update-fnnction  :  nap(switch,  symbol) 
coa^uted-using 

8vitch-ttpdata-function(z)  >  'switcb-updato 
var  and-gate-input-data  :  setCio^ort-obj)  »  < 


set-attrs  (mako-objoct  (’ioqport-obj) , 
’inqport-naiM,  *inl, 

'import -catogcry,  'signal, 
'ia^ort-typo-data,  'boolsan). 


sat-attrs  (maks-objsct  ( ' is^ort-ob j ) , 

' import-namo ,  ’ in2 , 

'import-category,  'signal, 
'in^ort-type-data,  'boolean)} 

var  and-gate-output-data  :  8et(export-obj)  =  { 


set-attrs  (mak^  object  ('export-obj), 

' export-name ,  ' ontl , 

'export -category,  'signal, 

'erport-type-data,  'boolean)} 

var  and-gate-coefficients  :  map(and-gate,  set(name-value-obj)) 
computed-using 

and-gate-coefficients (x)  =  {} 

form  HAKE-and-gate-NANES-UMiqUE 

unique-names-classC'and-gate,  true) 

"gate  (abstract-class)  1" 
var  and-gate-delay  :  map(and-gate,  integer) 
computed-using 

and-gate-delay(x)  =  0 

"gate  (abstract-class)  2" 

var  and-gate-mil-spec?  :  map(and-gate,  boolean) 
conq>uted-u8ing 

and-gate-mil-spec?(x)  =  nil 

"gate  (abstract-class)  3" 

var  and-gate-pouer-level  :  map(and-gate,  real) 
coiiq>uted-using 

and-gate-pouer-level(x)  =0.0 
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"This  is  ths  nams  of  ths  company  that  manufactnrsd  the  gats" 
var  and-gata-manufacturer  :  map(and-gata,  string) 
conqputsd-using 

and-gata-manufacturer(x)  =  "none  specified" 

function  AND-GATE-UPDATEl  (subsystem  :  subsystam-obj , 

and-gate  :  AND-GATE)  - 

format (debug-on,  "AND-GATE-OBJ-UPDATE  on  name(and-gate)) ; 

let  (ini  :  boolean  »  get-io^ort(’inl,  subsystem,  and-gate), 
in2  :  boolean  »  get-import (’in2,  subsystem,  and-gate)) 

set-export (subsystem,  and-gate,  *outl,  ini  A  in2) 


function  AND-GATE-UPDATE2  (subsystem  :  subsystem-obj , 

and-gate  :  AND-GATE)  > 

format (t,  "AND-GATE-OBJ-OPDATE2  on  "s"%",  name (and-gate)) 

var  and-gate-update-function  :  map(and-gate,  symbol) 
computed-using 

and-gate-update-function(x)  =  ’AHD-GATE-UPDATEl 

vax  nor-gate-bitmap-1  any-type  = 

cv: :expr-to-bitmap(ita8ca: : send (’bitmap,  itasca:  :select-any(’icon-obj, 
list(’equal,  ’name,  "nor-gate-bitmap-1")))) 

var  nor-gate-bitmap-s  any-type  = 

cv: :expr-to-bitmap(itasca; : send (’bitmap,  itasca: :s9lect-any(’icon-obj , 
list (’equal,  ’name,  "nor-gate-bitmap-s")))) 

var  decoder-bitmap-1  any-type  * 

c«: :expr-to-bitmap( itasca: : send (’bitmap,  ituca: :select-any(’icon-obj , 
list(’equal,  ’name,  "decoder-bitmap-1")))) 

var  decoder-bitmap-s  any-type  = 

cv : :  expr-to-bitmap( itasca: :  send(  ’bitmap ,  itasca: :  select-any ( ’  icon-ob j , 
list (’equal,  ’name,  "decoder-bitmap-s")))) 

var  nand-gate-bitmap-1  any-type  = 

cv: :expr-to-bitmap(itasca: :send( ’bitmap,  itasca: :select-any( ’icon-ob j , 
list(’equal,  ’name,  "nand-gate-bitmap-1")))) 

var  nand-gate-bitmap-s  any-type  = 

cv: :expr-to-bitmap(ita8ca: :send( ’bitmap,  itasca: : select-any (’ icon-ob j , 
list(’equ2il,  ’name,  "nand-gate-bitmap-s")))) 

var  or-gate-bitmap-1  :  any-type  = 

cv: :expr-to-bitmap(itasca: :send( ’bitmap,  itasca: :8elect-any(’icon-obj , 
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llBt(*«qual,  ’name,  "or-gate-bitnap-l")))) 


▼ar  or-gate-bitmap-8  any-typa  * 

cv: :expr-to-bitmap(ita8ca: : sand ('bitmap,  itaaca: :salect-any(’icoii-obj , 
liatC equal,  'name,  "or-gate-bitmap-a")))) 

var  led-bitmap-1  any-type  = 

c«: :ezpr-to-bitmapCitaaca: :aexid( 'bitmap,  itaaca:  :aelect-aiiy('icon-obj , 
li8t(' equal,  'name,  "led-bitmap-1")))) 

var  led-bitmap-s  any-type  * 

cv: :ezpr-to-bitfflap( itaaca: :8end( 'bitmap,  itaaca: :8elect-any('icon-obj , 
listC'equal,  'name,  "led-bitmap-a")))) 

var  jk-flip-flop-bitmap-1  any-type  = 

cw: :ezpr-to-bitmap(ita8ca: :8end( 'bitmap,  itaaca: :8elect-any( *icon-obj , 
liatC 'equal,  'name,  "jk-flip-flop-bitmap-1")))) 

var  jk-f lip-flop-bitmap-8  any-type  = 

cw: :ezpr-to-bitmap(itaaca; :8end( 'bitmap,  itaaca:  :8elect-any( 'icon-obj , 
li8t('equ2Q.,  'name,  " jk-flip-flop-bitmap-a")))) 

var  half-adder-bitmap-1  any-type  = 

cw: :expr-to-bitmap(ita8ca: :8end( 'bitmap,  itaaca: :8elect-any(' icon-obj , 
liatC'equal,  'name,  "half -adder-bitmap-1")))) 

var  half-adder-bitmap-8  any-type  = 

cw: :expr-to-bitmap( itaaca: :8end( 'bitmap,  itaaca: :8elect-any(’ icon-obj , 
listC'equal,  'name,  "half-adder-bitmap-s")))) 

var  counter-bitmap-1  :  any-type  = 

cw: :expr-to-bitmap(ita8ca: : send ('bitmap,  itaaca: :aelect-any(’ icon-obj , 
listC'equal,  'name,  "counter-bitmap-1")))) 

var  counter-bitmap-s  any-type  = 

cw: :expr-to-bitmap(itasca: :send( 'bitmap,  itaaca:  :8elect-any(' icon-obj , 
listC'equal,  'name,  "counter-bitmap-s")))) 

var  not-gate-bitmap-1  any-type  = 

cw: :ezpr-to-bitmap(itasca: :sendC'bitmap,  itasca: :select-any(' icon-obj, 
listC’equal,  'name,  "not-gate-bitmap-1")))) 

var  not-gate-bitmap-s  any-type  = 

cw: :expr-to-bitmap( itasca: : send ('bitmap,  itaaca: :8elect-any(’ icon-obj , 
listC’equeil,  'name,  "not-gate-bitmap-s")))) 

var  muz-bitmap-1  any-type  = 

cw: :ezpr-to-bitmap(itasca: :send( 'bitmap,  itaaca: :select-any(’ icon-obj , 
listC’equal,  'name,  "nnuc-bitmap-l")))) 

var  muz-bitmap-s  any-type  = 
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cv: :expr-to-bitmap(itasca: :send( ’bitmap.  Itasca: tselsct-anyC’icon-obj , 
Ii8t(’squ2d,  ’nams,  "moz-bitmap-s")))) 

var  switch-bitmap-1  any-type  = 

cw: :expr-to-bitmap(itasca: :seiid( 'bitmap,  itasca: rselect-anyC’icon-obj , 
listC’equal,  ’name,  "awitch-bitmap-1")))) 

var  svitch-bitmap-8  any-type  = 

cw: :expr-to-bitmap( itasca: : send (’bitmap,  itasca: :8elect-any( ’icon-obj , 
listC’equal,  ’name,  "switch-bitmap-s")))} 

var  and-gate-bitmap-1  any-type  = 

cw: :expr-to-bitmap(itasca: : send (’bitmap,  itasca: :select-any(’ icon-obj , 
listC’equal,  ’name,  "and-gate-bitmap-1")))) 

var  and-gate-bitmap-s  any-type  = 

cw: :ezpr-to-bitmap(ita8ca: :send(’ bitmap,  itasca: :select-any(’ icon-obj , 
listC’equal,  ’name,  "and-gate-bitmap-s")))) 


form  build-CIRCUITS-vsl-obj 

set-attr sCmake-ob j  ect  C ’ viz-spec-ob j ) , 
’name,  ’CIRCUITS, 

’re: :zl-documentation, 

"This  is  the  CIRCUITS  domain" , 

’class-specs,  [ 

set-attrs  (make-object  C’class-spec-obj) , 
’class-name,  ’nor-gate, 

’Icon- Attributes,  [ 

set-attrs  (make-object  (’Icon-Attr-Obj), 
’ icon-attr-name ,  ’ clip-icon-label? , 

’ icon-attr-val ,  f eClse) , 

set-attrs  (make-object  (’Icon-Attr-Obj), 
’icon-attr-name,  ’label, 

’ icon-attr-vzd ,  ’ class-and-name) , 

set-attrs  (make-object  (’Icon-Attr-Obj), 
’ icon-attr-name ,  ’border-thickness , 

’ icon-attr-ved. ,  0), 

set-attrs  (make-object  (’Icon-Attr-Obj), 
’icon-attr-name,  ’bitmap4icon-l, 

’ icon-attr-val ,  ’nor-gate-bitmap-l) , 

set-attrs  (make-object  (’Icon-Attr-Obj), 
’icon-attr-name,  ’bitmap4icon-s, 
’icon-attr-val,  ’nor-gate-bitmap-s)] , 
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*Edit-Attribut«8,  [ 


set-attrs  (make-objact  (’Edit-Attr-Obj), 
* adit-attr-nana ,  ’ dalay , 
'adit-attr-typa,  ’Intagar), 

sat-atcrs  (maka-objact  (’Edit-Attr-Obj) , 
’adit-attr-nana,  ’mil-apac?, 
’adit-attr-typa,  ’boolaan), 

sat-attra  (maka-objact  (*Edit-Attr-Obj) , 
’adit-attr-nama,  ’povar-laval, 
’adit-attr-typa ,  ’raal) , 

aat-attra  (maka-objact  (’Edit-Attr-Obj), 
’adit-attr-nama,  ’manufacturar , 
’adit-attr-typa,  ’atring), 

sat-attra  (maka-objact  (’Edit-Attr-Obj', 
’ adit-attr-nama ,  ’nama , 
’adit-attr-typa ,  ’ symbol)] ) , 


set-attrs  (maka-objact  (’claas-apac-obj) , 

’ class-nama ,  ’ dacodax , 

’Icon-Attributes,  [ 

sat-attra  (maka-objact  (’Icon-Attr-Obj) , 
’ icon-attr-name ,  ’ clip-icon-labal? , 

’ icon-attr-val ,  fedsa) , 

set-attrs  (maka-objact  (’Icon-Attr-Obj), 
’ icon-attr-nama ,  ’ label , 

’ icon-attr-val ,  ’ class-and-nama) , 

set-attrs  (make-object  (’Icon-Attr-Obj), 
’ icon-attr-name ,  ’border-thickness , 
’icon-attr-val,  0), 

set-attrs  (maka-objact  (’Icon-Attr-Obj), 
’icon-attr-name,  ’bitmap4icon-l, 

’ icon-attr-vad ,  ’decoder-bitmap-1) , 

set-attrs  (make-object  (’Icon-Attr-Obj), 
’icon-attr-nama,  ’bltmap4icon-s, 
’icon-attr-val,  ’dacodar-bitmap-s)] , 

’Edit-Attributes,  [ 

set-attrs  (make-object  (’Edit-Attr-Obj), 
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’•dit-attr-naffl«,  ’delay, 

’ edit-attr-typa ,  ’ integer) , 

eet-attrs  (make-object  (’Edit-Attr-Obj) , 
’edit-attr-name,  ’mil-apec?, 

’ edit-attr-type ,  ’boolean) , 

set-attrs  (make-object  (’Edit-Attr-Obj), 
’edit-attr-name,  ’power-level, 
’edit-attr-type,  ’real), 

set-attrs  (make-object  (’Edit-Attr-Obj), 
’ edit-attr-name ,  ’manufacturer , 

’edit -attr-type ,  ’ string) , 

set-attrs  (make-object  (’Edit-Attr-Obj), 
’ edit-attr-name ,  ’ name , 

’ edit-attr-type ,  ’ symbol)] ) , 


set-attrs  (make-object  (’class-spec-obj), 

’class-name,  ’nand-gate, 

’ Icon-Attributes ,  C 

set-attrs  (make-object  (’Icon-Attr-Obj) , 

’ icon-attr-name ,  ’ clip-icon-label? , 
’icon-attr-val,  false), 

set-attrs  (make-object  (’Icon-Attr-Obj), 
’icon-attr-name,  ’label, 

’ icon-attr-val ,  ’ class-and-name) , 

set-attrs  (make-object  (’Icon-Attr-Obj), 

’ icon-attr-name ,  ’border-thickness , 
’icon-attr-val,  0), 

set-attrs  (make-object  (’Icon-Attr-Obj), 
’icon-attr-name,  ’bitmap4icon-l, 

’ icon-attr-vad ,  ’nand-gate-bitmap-1) , 

set-attrs  (make-object  (’Icon-Attr-Obj), 

’ icon-attr-name ,  ’bitmap4icon-s , 

’ icon-attr-vad ,  ’nand-gate-bitmap-s)] , 

’Edit-Attributes,  [ 

set-attrs  (make-object  (’Edit-Attr-Obj), 
’edit-attr-name,  ’delay, 
’edit-attr-type ,  ’ integer) , 

set-attrs  (make-object  (’Edit-Attr-Obj), 
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’•dit-attr-nan»,  ’mil-apac?, 
'edit-attr-type,  ’boolaan), 

aet-attxB  (make-object  (*Edit-Attr-Obj) , 
*edit-attr-name,  ’power-level, 
’edit-attr-type,  ’real), 

set-attrs  (make-object  (’Edit-Attr-Obj) , 
’edit-attr-name,  ’manufacturer, 

’ edit-attr-type ,  ’ string) , 

set-attrs  (make-object  (’Edit-Attr-Obj), 
’edit-attr-name,  ’name, 
’edit-attr-type,  ’s3rmbo)-)] ) . 


set-attrs  (make-object  (’class-spec-obj), 

’ class-name ,  ’ or-gate , 

’Icon-Attributes,  [ 

set-attrs  (make-object  (’Icon-Attr-Obj), 
’ icon-attr-name ,  ’ clip-icon-label? , 

’ icon-attr-val ,  false), 

set-attrs  (make-object  (’Icon-Attr-Obj), 
’ icon-attr-name ,  ’ label , 

’ icon-attr-val ,  ’ class-and-name) , 

set-attrs  (make-object  (’Icon-Attr-Obj), 
’ icon-attr-name ,  ’border-thickness , 
’icon-attr-val,  0), 

set-attrs  (make-object  (’Icon-Attr-Obj), 
’icon-attr-name,  ’bitmap4icon-l, 

’ icon-attr-val ,  ’ or-gate-bitmap-1) , 

set-attrs  (make-object  (’Icon-Attr-Obj), 
’icon-attr-name,  ’bitmap4icon-s, 
’icon-attr-val,  *or-gate-bitmap-s)] , 

’Edit-Attributes,  [ 

set-attrs  (make-object  (’Edit-Attr-Obj), 
’edit-attr-name,  ’delay, 

’ edit-attr-t3^e ,  ’ integer) , 

set-attrs  (make-object  (’Edit-Attr-Obj), 
’edit-attr-name,  ’mil-spec?, 

’ edit-attr-type ,  ’ boolean) , 

set-attrs  (make-object  (’Edit-Attr-Obj), 
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’•dit-attr-naiM,  *po«er-lov«l, 
’•dit-attr-typ«,  *r«al), 

sat-attrs  (maka-object  (’Edit-Attr-Obj), 
’adit-attr-nama,  ’manufacturar, 

‘ adit-attr-typa ,  *  string) , 

sat-attrs  (maka-objact  CEdit-ittr-Obj) , 
*  adit-attr-nama ,  ’ nama . 
’adit-attr-typa,  ’symbol)]). 


sat-att  (maka-objact  (’class-spac-obj) , 

’claas-name,  ’lad, 

’ Icon-Attributas ,  [ 

sat-attrs  (maka-objact  (’Icon-Attr-Obj), 
’ icon-attr-nama ,  ’ clip-icon-labal? , 

’ icon-attr-v2d ,  falsa), 

sat-attrs  (maka-objact  (’Icon-Attr-Obj), 
’icon-attr-nama,  ’label, 

’ icon-attr-val ,  ’ class-and-nama) , 

sat-attrs  (maka-objact  (’Icon-Attr-Obj), 
’ icon-attr-nama ,  ’ bordar-thicknasa , 
’icon-attr-val,  0), 

sat-attrs  (maka-objact  (’Icon-Attr-Obj), 
’ icon-attr-nama ,  ’bitmap4icon-l , 

’ icon-attr-veG. ,  ’ lad-bitmap-1) , 

sat-attrs  (maka-objact  (’Icon-Attr-Obj), 
’icon-attr-nama,  ’bitmap4icon-s, 
’icon-attr-val,  ’lad-bitmap-s)] , 

’ Edit-Attributas ,  [ 

set-attrs  (maUEe-objact  (’Edit-Attr-Obj), 
’ adit-attr-nama ,  ’ color , 

’ adit-attr-typa ,  ’ symbol) , 

sat-attrs  (maka-objact  (’Edit-Attr-Obj), 
’adit-attr-nama,  ’manufacturer, 

’ adit-attr-typa ,  ’ string) , 

set-attrs  (maka-objact  (’Edit-Attr-Obj), 
’ adit-attr-nama ,  ’ name , 

’ adit-attr-typa ,  ’ symbol)] ) , 
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■«t-&ttra  (nak«-obj«ct  ('class-spac-obj) . 

’clMS-nanw,  *jk-f lip-flop, 

’ Icon-Attributos ,  [ 

8«t-attrs  (mako-objoct  (’Icon-Attr-Obj), 

’ icon-attr-namo ,  ’ clip-icon-labal? , 

' icon-attr-val ,  falsa), 

sat-attrs  (maka-objact  (’Icon-Attr-Obj), 

* icon-attr-nama ,  * labal , 

‘ icon-attr-val ,  ’ class-and-nama) , 

sat-attrs  (maka-objact  <'Icon-Attr-Obj), 

’ icon-attr-nama ,  ’bordar-thicknass , 

* icon-attr-val ,  0) , 

sat-attrs  (maka-objact  (*Icon-Attr-0bj), 

’ icon-attr-nama ,  ’bitmap4icon-l , 

* icon-attr-val ,  ’ jk-f lip-flop-bitmap-1) , 

sat-attrs  (maka-objact  (’Icon-Attr-Obj), 
’icon-attr-nama,  *bitmap4icon-a, 

' icon-attr-val ,  ’ jk-f lip-f lop-bitmap-s)] , 

’Edit-Attributas,  [ 

sat-attrs  (maka-objact  (’Edit-Attr-Obj), 
’adit-attr-nama,  ’sat-up-dalay, 

’ adit-attr-typa ,  * intagar ) , 

sat-attrs  (maka-objact  (’Edit-Attr-Obj), 
’adit-attr-nama,  ’hold-dalay, 
’adit-attr-typa,  ’raal) , 

sat-attrs  (naka-objact  (’Edit-Attr-Obj), 
’adit-attr-nama,  ’dalay, 

’adit-attr-typa ,  ’ intagar) , 

sat-attrs  (maka-objact  (’Edit-Attr-Obj), 
’adit-attr-nama,  ’mil-spac?, 
’adit-attr-typa,  ’boolaan), 

sat-attrs  (maka-objact  (’Edit-Attr-Obj), 
’adit-attr-nama,  ’powar-laval, 

’ adit -attr-typa ,  ’ raal ) , 

sat-attrs  (maka-objact  (’Edit-Attr-Obj), 

’ adit-attr-nama ,  ’manuf acturar , 

’ adit-attr-typa ,  ’ string) , 

sat-attrs  (maka-objact  (’Edit-Attr-Obj), 
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*  cdit-attr-naiM ,  'nanM , 
’•dit-attr-typ«,  ’symbol)]). 


set-attrs  (maka-objsct  (’clasa-spac-obj), 

’ class-nams ,  ’balf-addsr , 

’ Icon-Attributes ,  [ 

set-attrs  (make-object  (’Icon-Attr-Obj), 

’ icon-attr-name ,  ’ clip-icon-label? . 

’ icon-attr-val ,  false), 

set-attrs  (make-object  (’Icon-ittr-Obj), 
’icon-attr-name,  ’label, 

’ icon-attr-val ,  ’ class-and-name) , 

set-attrs  (make-object  (’Icon-lttr-Obj), 

’ icon-attr-name ,  ’border-thickness , 

’ icon-attr-val ,  0) , 

set-attrs  (make-object  (’Icon-Attr-Obj), 
’icon-attr-name,  ’bitmap4icon-l, 

’ icon-attr-val ,  ’half -adder-bitmap-1) , 

set-attrs  (make-object  (’Icon-Attr-Obj), 
’icon-attr-name,  ’bitmap4icon-8, 
’icon-attr-val,  ’half-adder-bitmap-s)] , 

’Edit-Attributes,  [ 

set-attrs  (make-object  (’Edit-Attr-Obj), 
’edit-attr-name,  ’delay, 

’ edit-attr-type ,  ’ integer) , 

set-attrs  (make-object  (’Edit-Attr-Obj), 
’edit-attr-name,  ’mil-spec?, 
’edit-attr-type,  ’boolean), 

set-attrs  (make-object  (’Edit-Attr-Obj), 
’edit-attr-name,  ’power-level, 
’edit-attr-type ,  ’real) , 

set-attrs  (nuQce-object  (’Edit-Attr-Obj), 
’edit-attr-name,  ’manufacturer, 

’ edit-attr-type ,  ’ string) , 

set-attrs  (make-object  (’Edit-Attr-Obj), 
’edit-attr-name,  ’name, 

’ edit-attr-type ,  ’ symbol)] ) , 
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■•t-attrs  (naka-objact  (’claaa-apac-obj), 

'claas-oaaa,  ’coantar, 

'Icon-Attributaa.  C 

sat-attrs  (maka-objact  (*Icon-Attr-Obj), 
* icon-attr-nana ,  *  clip-lcon-labal? , 
'icon-attr-val,  falsa), 

sat-attrs  (maka-objact  < ’ leon-Attr-Obj ) , 
* icon-attr-nama ,  'labal, 

* icon-attr-val ,  ’ class-and-nama) , 

sat-attrs  (maka-objact  (’Icon-Attr-Obj), 
* icon-attr-nama ,  ’bordar-tblcknass, 

’ icon-attr-val ,  0) , 

sat-attrs  (maka-objact  (* Icon-Attr-Obj), 
' icon-attr-nama ,  ’bitmap4icon-l, 

’ icon-attr-val ,  ' countar-bitmap-1) , 

sat-attrs  (maka-objact  (’Icon-Attr-Obj), 
’ icon-attr-nama ,  ’bitmap4icon-s, 

* icon-attr-val ,  ' countar-bitmap-s) j , 

’Edit-Attributas,  C 

sat-attrs  (maka-objact  (’Edit-Attr-Obj) , 
’adit-attr-nama,  ’tha-count, 
*adit-attr-typa ,  ’intagar) , 

sat-attrs  (maka-objact  (’Edit-Attr-Obj), 
’adit-attr-nama,  ’dalay, 

’ adit-attr-typa ,  ’ intagar) , 

sat-attrs  (maka-objact  (’Edit-Attr-Obj), 
’adit-attr-nama,  ’mil-spac?, 

’ adit-attr-typa ,  ’ boolaan) , 

sat-attrs  (maka-objact  (’Edit-Attr-Obj), 
’adit-attr-nama,  ’povar-laval, 
’adit-attr-typa,  ’r«:al), 

sat-attrs  (maka-objact  (’Edit-Attr-Obj), 
’adit-attr-nama,  ’manuf acturar , 

’ adit-attr-typa ,  *  string) , 

sat-attrs  (maka-objact  (’Edit-Attr-Obj), 
’ adit-attr-nama ,  ’nama , 
’adit-attr-typa,  ’syiid>ol)] ) , 
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■•t-attrs  (maka-objact  (*class-spac-obj), 

’claaa-nama,  'not-gata, 

' Icon-Attributas ,  [ 

aat-attrs  (maka-objact  (’Icoa-Attr-Obj). 
* icon-attr-nama ,  *clip-icoa-labal?. 

' icon-attr-val ,  falsa), 

sat-attrs  (maka-objact  (’Icoa-Attr-Obj) . 
’ icon-attr-nama ,  'labal, 

’ icon-attr-tal ,  *  class-and-nama) , 

sat-attrs  (maka-objact  (*IcoB-Attr-Obj), 
'icon-attr-nama,  'bordar-thicknass, 

' icon-attr-val ,  0), 

sat-attrs  (maka-objact  ('Icon-Attr-Obj) , 
'icon-attr-nama,  'bitmap4icon-l, 

' icon-attr-val ,  ' not-gata-bitmap-1) , 

sat-attrs  (maka-objact  ('Icon-Attr-Obj), 
'icon-attr-nama,  'bitm^>4icon-a, 

' icon-attr-ral ,  'not-gata-bitmap-s)] , 

'Edit-Attributas,  [ 

sat-attrs  (maka-objact  ('Edit-Attr-Obj), 
'adit-attr-nama,  'dalay, 

' adit-attr-typa ,  ' intagar) , 

sat-attrs  (maka-objact  ('Edit-Attr-Obj), 
'adit-attr-nama,  'mil-spac?, 

' adit -attr-typa ,  ' boolaan) , 

sat-attrs  (maka-objact  ('Edit-Attr-Obj), 
'adit-attr-nama,  'povar-laval, 

' adit-attr-typa ,  ' raal) , 

sat-attrs  (maka-objact  ('Edit-Attr-Obj), 
'adit-attr-nama,  'manufactnrar, 

' adit-attr-typa ,  ' string) , 

sat-attrs  (maka-objact  ('Edit-Attr-Obj), 
' adit-attr-nama ,  'nama , 

' adit-attr-typa ,  ' symbol)] ) , 


sat-attrs  (maka-objact  ('class-spac-obj), 
'class-nama,  'muz, 

' Icon-Attributas ,  [ 


B.35 


Mt-*«ttrs  (aakt-objtct  (*IcoB-ittr-Obj). 
* Icon-attr-uuM ,  'clip-icon- label?, 

* icon-attr-val ,  falso), 

sat-attrs  (mako-objoct  ( ' Icon-Attr-Obj ) • 
’ icon-attr-naao ,  'label, 
'icon-attr-val,  'clasa-and-nane), 

set-attrs  (make-object  Clcon-Attr-Obj), 
' icon-attr-name ,  'border-thickness, 
'icon-attr-val,  0), 

set-attrs  (make-object  ('Icon-Attr-Obj), 
'icon-attr-name,  'bitmsp4icon-l, 

* icon-attr-val ,  ’moz-bitmap-l) , 

set-attrs  (make-object  (' Icon-Attr-Obj ) , 
'icon-attr-name,  'bitmap4icon-s, 
'icon-attr-val,  'mux-bitmap-s)] , 

'Edit-Attributes,  [ 

set-attrs  (make-object  CEdit-Attr-Obj), 
' edit-attr-name ,  'delay, 

' edit-attr-type ,  ' integer) , 

set-attrs  (make-object  CEdit-Attr-Obj), 
'edit-attr-name,  'mil-spec?, 
'edit-attr-type ,  'boolean) , 

set-attrs  (make-object  CEdit-Attr-Obj), 
'edit-attr-name,  'power-level, 
'edit-attr-type,  'real), 

set-attrs  (make-object  CEdit-Attr-Obj), 
'edit-attr-name,  'manufacturer, 

' edit-attr-type ,  ' string) , 

set-attrs  (oudce-object  CEdit-Attr-Obj), 
' edit-attr-name ,  'name , 

' edit-attr-type ,  ' symbol)] ) , 


set-attrs  (make-object  Cclass-spec-obj), 

’ class-name ,  ' switch , 

' Icon-Attributes ,  [ 

set-attrs  (make-object  (' Icon-Attr-Obj ) , 
'icon-attr-name,  'clip-icon-label?, 
'icon-attr-val,  false). 
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■•t-attrs  (mak«-obj«ct  ('Icon-Attr-Obj), 
’ icon-attr-naiM ,  ’ labal , 

'  icon-attr-val ,  *  class-and-naM) , 

sat-attra  (maka-objact  ('Icon-Attr-Obj), 
’ icon-attr-nama ,  'bordar-thlcknaas, 
'icon-attr-val,  0), 

sat-attrs  (maka-objact  ('Icon-Attr-Obj), 
'icon-attr-nama,  'bitmap4icon-l, 

' icon-attr-val ,  ' avitch-bitmap-l) , 

sat-attrs  (maka-objact  ('Icon-Attr-Obj), 
'icon-attr-nama,  'bitmap4icon-s, 

' icon-attr-val ,  ' svitch-bitmap-s)] , 

'Edit-Attributas,  [ 

sat-attrs  (maka-objact  ('Edit-Attr-Obj) , 
' adit-attr-nama ,  ' dalay , 

' adit-attr-typa ,  ' intagar ) , 

sat-attrs  (maka-objact  ('Edit-Attr-Obj), 
' edit -attr-nama ,  ' dabonncad , 
'adit-attr-typa,  ’boolean), 

sat-attrs  (maka-objact  (’Edit-Attr-Obj), 
'adit-attr-nama,  'tha-position, 
'adit-attr-typa,  'syna>ol), 

sat-attrs  (maka-objact  (’Edit-Attr-Obj), 
' adit-attr-nama ,  'manof acturar , 

' adit-attr-typa ,  ’ string) , 

sat-attrs  (oudca-objact  (’Edit-Attr-Obj), 
’ adit-attr-nama ,  'name , 
'adit-attr-typa,  ’symbol)]). 


sat-attrs  (maka-objact  (’class-spac-obj), 

’ class-nama ,  ’ and-gata , 

'Icon-Attributes,  [ 

sat-attrs  (maka-objact  (’Icon-Attr-Obj), 
’ icon-attr-nama ,  ' clip-icon-labal? , 

' icon-attr-val ,  falsa) , 

sat-attrs  (uAka-objaet  (’Icon-Attr-Obj), 
’ icon-attr-nama ,  ’ labal , 

’ icon-attr-val ,  ’ class-and-nama) , 
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••t-»ttr*  (Bak«-obj«ct  ('Icon-ittr-Obj), 

*  icon-attr-naiM ,  *bord«r-tbickii«ss, 

' icon-attr-val ,  0), 

8«t-attr5  (make-obj«ct  ('Icoa-Attr-Obj), 

’  icon-attr-oaiB* ,  *  bltaapAicoa-l , 

'icon-attr-val,  'and-gata-bitmap-  1). 

aat-attra  (maka-objact  (’Icon-Attr-Obj) , 

' icon-attr-nama ,  'bitmap4icon-a, 

’ icon-attr-val ,  ' and-gata-bitmap-a)] , 

'Edit-Attributaa,  [ 

sat-attrs  (maka-objact  (’Edit-Attr-Obj), 

'adit-attr-nama,  'dalay, 

’ adit-attr-typa ,  ' intagar) , 

sat-attra  (maka-objact  ('Edit-Attr-Obj). 

'adit-attr-nama,  'mil-apac?, 

’ adit-attr-typa ,  'boolaan) , 

aat-attra  (maka-objact  ('Edit-Attr-Obj), 

'adit-attr-nama,  'povar-laval, 

'adit-attr-typa,  'raal), 

aat-attra  (maka-objact  ('Edit-Attr-Obj), 

'adit-attr-nama,  'manufacturar, 

' adit-attr-typa ,  ' atring) , 

aat-attra  (maka-objact  ('Edit-Attr-Obj), 

' adit-attr-nama ,  'nama , 

'adit-attr-typa,  'aymbol)])]) 

! !  in-grammar  ( ’  a3rntaz) 

grammar  CIRCUITS 

no-pattama 

inherit a-from  OCU 

atart-claaaas  Spac-Obj ,  aubayatam-obj ,  incon^lata-obj ,  Ganaric-obj ,  Application-obj , 

nor-gate , 

decoder , 

nand-gata , 

or-gata , 

lad, 

jk-f lip-flop, 
half -adder , 
counter , 
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not-gat« , 

DOZ, 

switch , 

and-gats,  Ezprsssion 


file-classes  Spec-Obj,  sabsystea-obj ,  inc<uqplete-obj .  Generic-obj,  ipplication-obj . 

nor-gate , 

decoder, 

nand-gate , 

or-gate , 

led, 

jk-f lip-flop, 
half-adder , 
counter , 
not-gate , 
mux, 
switch, 
and-gate 


productions 


nor-gate  C"nor-gate"  name 

{["delay:"  nor-gate-delay] 

[< ["mil-spec"  !!  nor-gate-mil-spec?]  1 
["not  mil-spec"  "!!  nor-gate-mil-spec?])] 
["manufacturer: "  nor-gate-manufacturer] 
["power  level:"  nor-gate-power-level]  >  ] 
builds  nor-gate , 

decoder  ::s  ["decoder"  name 

{ ["delay : "  decoder-delay] 

[( ["mil-spec"  ! !  decoder-mil-spec?]  I 
["not  mil-spec"  "!!  decoder-mil-spec?])] 
["manufacturer:"  decoder-manufacturer] 
["power  level:"  decoder-power-level]  }  ] 
builds  decoder , 

nand-gate  : :=  ["nand-gate"  name 

{["delay:"  nand-gate-delay] 

[(["is  mil-spec"  !!  nand-gate-mil-spec?]  1 
["not  mil-spec"  "!!  nand-gate-mil-spec?])] 
["manufacturer : "  nand-gate-manuf acturer] 
["power  level:"  nand-gate-power-level]  }  ] 
builds  nand-gate , 
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or-gat« 


led 


jk-flip-flop 


h2dl-addex 


coimter 


not-gate 


noiz 


C"or-gate"  name 
{["delay:"  or-gate-delay] 

[(["is  mil-spec"  M  or-gate-mil-spec?]  I 
["not  mil-spec"  " ! !  or-gate-mil-spec?] )] 
[•‘manufacturer : "  or-gate-manuf acturer] 
["power  level:"  or-gate-power-level]  }  ] 
builds  or-gate , 


["led"  name 

{["manufacturer:"  led-manuf acturer] 

["color:"  led-color]  )■  ] 
builds  led. 

::=  ["jk-flip-flop"  name 

{["delay:"  jk-f lip-flop-delay] 

[(["is  mil-spec"  !!  jk-f lip-flop-mil-spec?]  | 
["not  mil-spec"  '!!  jk-f lip-flop-mil-spec?])] 
["manufacturer : "  jk-f lip-flop-manufacturer] 
["power  level:"  jk-f lip-flop-power-level] 
["set-up  delay:"  jk-f lip-flop-set-up-delay] 
["hold  delay:"  jk-f lip-flop-hold-delay] 
[(["state  on"  !!  jk-f lip-flop-state] | 

["state  off"  '!! jk-f lip-flop-state] )  ]  }  ] 
builds  jk-flip-flop, 

: :»  ["half -adder"  name 

{ ["delay : "  half-adder-delay] 

[(["mil-spec"  !!  half-adder-mil-spec?]  I 
["not  mil-spec"  "!!  half-adder-mil-spec?])] 
["manufacturer : "  half-adder-manuf acturer] 
["power  level:"  hzdf-adder-power-level]  }  ] 
builds  half -adder , 

["counter"  name 
{ ["delay : "  counter-delay] 

["count:"  counter-the-count] 

[(["mil-spec"  !!  counter-mil-spec?]  I 
["not  mil-spec"  "!!  counter-mil-spec?])] 
["manufacturer : "  counter-manufacturer] 

["power  level:"  counter-power-level]  }  ] 
builds  counter , 

=  ["not-gate"  name 

{ ["delay : "  not-gate-delay] 

[(["is  mil-spec"  !!  not-gate-mil-spec?]  I 
["not  mil-spec”  " ! !  not-gate-mil-spec?] )] 
["manufacturer : "  not-gate-manuf acturer] 

["power  level:"  not-gate-power-level]  >  ] 
builds  not-gate, 

["mux"  name 
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{["delay:"  muz-dalay] 

[(["mil-spec"  !!  mux-mil-spec?]  I 
["not  mil-spec"  "!!  max-mil-spec?]}] 
["manuf  acturex : "  mux-manuf actuxer] 
["powex  level:"  mux-povex-level]  }  ] 
builds  mux , 


switch  : :=  ["switch"  name 

{ ["delay : "  switch-delay] 

[(["is  debounced"  !!  switch-debounced]  I 
["not  debounced"  *!!  switch-debounced]}] 
["manuf actuxex : "  switch-manulactuxex] 
["position:”  switch-the-position]  }  ] 
builds  switch, 

and-gate  ::=  ["and-gate"  name 

{["delay:"  and-gate-delay] 

[(["is  mil-spec"  !!  and-gate-mil-spec?]  I 
["not  mil-spec"  ' ! !  and-gate-mil-spec?] }] 
["manulactuxex:"  and-gate-manufactuxex] 

["powex  level:"  emd-gate-powex-level]  }  ] 
builds  and-gate 

symbol-staxt-chaxs 

"abedef ghi jklmnopqxstuvwxyzABCBEFGHIJKLMNOPQRSTUVWXYZ . /*" 
symbol-continue-chaxs 

"abedef ghi jklmnopqxstuvwxyxABCDEFGHIJKLMNOPQIlSTUVWXYZ-0123456789 . /*?" 
comments  "7,"  matching  " 


pxecedence 

fox  expxession  bxackets  "("  matching  "}" 

(same-level  "and",  "ox"  associativity  left}, 

(same-level  "<",  "=",  ">=",  ">",  "/="  associativity  none} , 

(same-level  associativity  left}, 

(same-level  "/",  "mod"  associativity  left}, 

(same-level  "not"  associativity  none}, 

(same-level  "abs"  associativity  none} , 

(same-level  "♦*"  associativity  xight} 


end 
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Appendix  C.  Technology  Base  Applications  from  Logic  Circuits  Domain 

This  appendix  contains  the  file-based  versions  of  the  applications  composed  for  the 
CIRCUITS  Domain. 

This  is  a  simple  test  application  that  uses  2  switches,  2  ‘'and"  gates,  and  2  LEDs. 


C.l  TEST  Application 

application  definition  TEST 
execution-mode :  NON-EVENT-DRIVEN-SEQOENTIAL 
application  TEST  is  controls:  SUB  update  procedure: 
update  SUB 

subsystem  SUB  is  controls:  L2,  LI,  A2.  Al,  S2.  SI 
imports : 

IN2  SIGNAL  BOOLEAN  Al  (  OUTl  SUB  A2 

)  import-path:  (  SUB  )  in^ort-ovner :  SUB 
INI  SIGNAL  BOOLEAN  Al  (  OUTl  SUB  SI 

)  import-path:  (  SUB  )  import - owner :  SUB 
IN2  SIGNAL  BOOLEAN  A2  (  OUTl  SUB  S2 

}  import-path:  (  SUB  )  iiq)ort-ovner :  SUB 
INI  SIGNAL  BOOLEAN  A2  (  OUTl  SUB  Al 

)  import -path:  (  SUB  )  import-owner:  SUB 
INI  SIGNAL  BOOLEAN  LI  (  OUTl  SUB  Al 

)  import-path:  (  SUB  )  import-owner:  SUB 
INI  SIGNAL  BOOLEAN  L2  (  OUTl  SUB  A2 

)  import-path:  (  SUB  )  import-owner:  SUB 
exports ; 

OUTl  SIGNAL  BOOLEAN  SI 

export-path;  (  SUB  )  export-owner:  SUB 
OUTl  SIGNAL  BOOLEAN  S2 

export-path:  (  SUB  )  export-owner:  SUB 
OUTl  SIGNAL  BOOLEAN  Al 

export -path:  (  SUB  )  export-owner:  SUB 
OUTl  SIGNAL  BOOLEAN  A2 

export -path:  (  SUB  )  export-owner:  SUB 
initialize  procedure:  update  procedure: 

update  SI  update  S2  update  Al  update  A2  update  LI  update  L2 
switch  SI  delay:  0  not  debounced  manufacturer:  "  " 
position:  ON  comp-x:  120  comp-y:  100 
switch  S2  delay:  0  not  debounced  manufacturer:  "  " 
position:  ON  comp-x:  120  comp-y:  200 
and-gate  Al  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  comp-x:  270  comp-y:  110 
and-gate  A2  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  comp-x:  272  comp-y;  234 
led  LI  manufacturer:  "  "  color:  RED  comp-x:  434  comp-y:  114 
led  L2  manufacturer:  "  "  color:  RED  comp-x;  434  coiq)-y:  241 
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C.2  ADDER  Application 


This  application  is  a  full  adder.  It  is  built  using  2  subsystems  that  are  half  adders,  built  out 
of  “and”,  “or”,  and  “not”  gates. 

application  definition  ADDER 
execution-mode :  NON-EVEMT-DRIVEN-SEqUENTIAL 
application  ADDER  is  controls:  ADDERl  update  procedure: 
update  ADDERl 

and-gate  HAl-ANDl  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  comp-z:  118  comp-y:  6S 
and-gate  HA1-AND2  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  comp-x:  117  comp-y:  194 
and-gate  HA1-AND3  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  comp-x:  118  comp-y:  298 
or-gate  HAl-OR  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  con^-x:  231  comp-y:  151 
and-gate  HA2-AND1  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  comp-x:  117  comp-y:  82 
and-gate  HA2-AND2  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  coiq>-x:  119  comp-y:  198 
and-gate  HA2-AND3  delay:  0  not  mil-spec  manufacturer:  "  ” 
power  level:  0.0  comp-z:  117  comp-y:  298 
or-gate  HA2-0R  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  comp-z:  231  comp-y:  146 
switch  SWITCH- 1 ADDEND  delay:  0  not  debounced 
manufacturer:  ”  "  position:  OFF  comp-x;  123  comp-y:  296 
switch  SWITCH-2ADDEND  delay:  0  not  debounced 
manufacturer:  "  "  position:  ON  coiq>-x:  120  coiq>-y:  198 
switch  SWITCH-3A0DEND  delay:  0  not  debounced 

manufacturer:  "  "  position:  OFF  comp-x:  240  co]q>-y:  400 
led  SUM-OOTPUT  manufacturer:  "  "  color:  RED  comp-x;  361 
con^-y :  94 

led  CARRY-OUTPUT  manufacturer:  "  "  color:  RED  con^-x:  242 
comp-y:  102 

not-gate  NOT-FIRSTX  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  con5)-x:  240  comp-y:  300 
not-gate  NOT-FIRSTY  delay:  0  not  mil-spec  mainufacturer:  "  " 
power  level:  0.0  comp-x:  240  conp-y;  200 
not-gate  NOT-SECONDX  delay:  0  not  mil-spec  amnufacturer:  "  ” 
power  level:  0.0  con^-x:  117  con5)-y;  400 
not-gate  NOT-SECONDY  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  coiq)-!:  411  coxq>-y:  392 
subsystem  ADDERl  is  controls: 

HAl,  HA2,  SWITCH- lADDEND,  SWITCH-2ADDEND ,  SWITCH-3ADDEND , 

NOT-FIRSTX,  NOT-FIRSTY,  NOT-SECONDX,  NOT-SECONDY, 

SUM-OUTPUT,  CARRY-OUTPUT,  LAST-OR 
imports : 

INI  SIGNAL  BOOLEAN  HAl-ANDl  (  OUTl  ADDERl  SWITCH- lADDEND 
)  in^ort-path:  (  ADDERl  HAl  )  import-owner:  EUll 
IN2  SIGNAL  BOOLEAN  HAl-ANDl  (  OUTl  ADDERl  NOT-FIRSTY 
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}  ijq>ort-path:  (  ADDERl  HAl  )  ii^ort-oniar :  HAl 
INI  SIGNAL  BOOLEAN  HA1-AND2  (  OUTl  ADDERl  NOT-FIRSTX 
)  in^ort-path :  (  ADDERl  HAl  }  iaport-onar :  HAl 
IN2  SIGNAL  BOOLEAN  HA1-AND2  (  OUTl  ADDERl  SWITC:H-2ADDEND 
)  in^ort-path;  (  ADDERl  HAl  }  ii^ort-oimar:  HAl 
INI  SIGNAL  BOOLEAN  HA1-AND3  (  OUTl  ADDERl  SWITCH- lADDEND 
)  in^ort-path:  (  ADDERl  HAl  )  iiiq>ort-OHn«r :  HAl 
IN2  SIGNAL  BOOLEAN  HA1-AND3  (  OUTl  ADDERl  SHITCH-2ADDEND 
)  import -path:  (  ADDERl  HAl  )  ioport - owner :  HAl 
INI  SIGNAL  BOOLEAN  HAl-OR  (  OUTl  HAl  HAl-ANDl 
)  import-path:  (  ADDERl  HAl  )  iBq;>ort-owner :  HAl 
IN2  SIGNAL  BOOLEAN  HAl-OR  (  OUTl  HAl  HA1-AND2 
)  iiq>ort-path:  (  ADDERl  HAl  )  isport-owner :  HAl 
INI  SIGNAL  BOOLEAN  HA2-AND1  (  OUTl  HAl  HAl-OR 
)  import-path:  (  ADDERl  HA2  )  import-owner:  HA2 
IN2  SIGNAL  BOOLEAN  HA2-AND1  (  OUTl  ADDERl  NOT-SECONDY 
)  import-path:  (  ADDERl  HA2  )  import -owner :  HA2 
INI  SIGNAL  BOOLEAN  HA2-AND2  (  OUTl  ADDERl  NOT-SECONDX 
)  import-path:  (  ADDERl  RA2  )  import-owner:  HA2 
IN2  SIGNAL  BOOLEAN  HA2-AND2  (  OUTl  ADDERl  SWITCH-3ADDEND 
)  import-path:  (  ADDERl  HA2  )  import-owner:  HA2 
INI  SIGNAL  BOOLEAN  HA2-AND3  (  OUTl  HAl  HAl-OR 
)  import-path:  (  ADDERl  HA2  )  import -owner:  EA2 
IN2  SIGNAL  BOOLEAN  HA2-AND3  (  OUTl  ADDERl  SWITCH-3ADDEND 
)  import -path:  (  ADDERl  HA2  }  import-owner:  HA2 
INI  SIGNAL  BOOLEAN  HA2-QR  (  OUTl  HA2  HA2-AND1 
)  import-path:  (  ADDERl  HA2  )  inport-owner:  HA2 
IN2  SIGNAL  BOOLEAN  HA2-0R  (  OUTl  HA2  HA2-AND2 
)  import-path:  (  ADDERl  HA2  )  import-owner:  HA2 
IN2  SIGNAL  BOOLEAN  LAST-OR  (  OUTl  HAl  HA1-AND3 
}  import -path:  (  ADDERl  )  import-owner:  ADDERl 
INI  SIGNAL  BOOLEAN  LAST-OR  (  OUTl  BA2  HA2-AND3 
)  import-path:  (  ADDERl  )  import-owner:  ADDERl 
INI  SIGNAL  BOOLEAN  CARRY-OUTPUT  (  OUTl  ADDERl  LAST-OR 
)  import-path:  (  ADDERl  )  import-owner:  ADDERl 
INI  SIGNAL  BOOLEAN  SUM-OUTPUT  (  OUTl  HA2  HA2-0R 
}  import-path:  (  ADDERl  )  import-owner:  ADDERl 
INI  SIGNAL  BOOLEAN  NOT-SECONDY  (  OUTl  ADDERl  SHITCH-3ADDEND 
)  import-path:  (  ADDERl  )  import-owner:  ADDERl 
INI  SIGNAL  BOOLEAN  NOT-SECONDX  (  OUTl  HAl  HAl-OR 
}  import -path:  (  ADDERl  )  import-owner;  ADDERl 
INI  SIGNAL  BOOLEAN  NOT-FIRSTY  (  OUTl  ADDERl  SWITCH-2ADDEND 
)  import-path:  (  ADDERl  }  import-owner:  ADDERl 
INI  SIGNAL  BOOLEAN  NOT-FIRSTX  (  OUTl  ADDERl  SWITCH- lADDEND 
)  import -path:  (  ADDERl  )  import-owner:  ADDERl 
exports: 

OUTl  SIGNAL  BOOLEAN  HAl-ANDl 

export -path:  (  ADDERl  HAl  )  export-owner:  HAl 
OUTl  SIGNAL  BOOLEAN  HA1-AND2 

export -path:  (  ADDERl  HAl  )  export-owner:  HAl 
OUTl  SIGNAL  BOOLEAN  HA1-AND3 
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export -path:  (  ADDERl  Bil  ) 
OUTl  SIGNAL  BOOLEAN  HAl-OR 
export-path:  (  ADDERl  HAl  ) 
OUTl  SIGNAL  BOOLEAN  HA2-AND1 
export -path:  (  ADDERl  HA2  ) 
OUTl  SIGNAL  BOOLEAN  HA2-AND2 
export-path:  (  ADDERl  HA2  ) 
OUTl  SIGNAL  BOOLEAN  HA2-AND3 
export -path:  (  ADDERl  EA2  ) 
OUTl  SIGNAL  BOOLEAN  HA2-0R 
export-path:  (  ADDERl  HA2  ) 
OUTl  SIGNAL  BOOLEAN  UST-OR 


export-owner:  HAl 
export-owner:  HAl 
export-owner:  HA2 
export-owner:  HA2 
export-owner:  HA2 
export-owner:  HA2 


export-path:  (  ADDERl  )  export-owner:  ADDERl 
OUTl  SIGNAL  BOOLEAN  NOT-SECONDY 


export -path:  (  ADDERl  )  export -owner:  ADDERl 
OUTl  SIGNAL  BOOLEAN  NOT-SECONDX 

export -path:  (  ADDERl  )  export -owner :  ADDERl 
OUTl  SIGNAL  BOOLEAN  NOT-FIRSTY 

export-path:  (  ADDERl  )  export-owner:  ADDERl 
OUTl  SIGNAL  BOOLEAN  NOT-FIRSTX 

export -path:  (  ADDERl  )  export -owner:  ADDERl 
OUTl  SIGNAL  BOOLEAN  SWITCH-3A0DEND 

export-path:  (  ADDERl  )  export-owner:  ADDERl 
OUTl  SIGNAL  BOOLEAN  SWITCH- 2AODEND 
export-path:  (  ADDERl  )  export-owner:  ADDERl 
OUTl  SIGNAL  BOOLEAN  SWITCH- 1 ADDEND 

export-path:  (  ADDERl  )  export-owner:  ADDERl 
initialize  procedure:  update  procedure: 
update  SWITCH-IADDEND  update  SWITCH-2ADDEND 

update  SWITCH-3ADDEND  update  NOT-FIRSTI  update  NOT-FIRSTY 
update  HAl  update  NOT-SECONDX  update  NOT-SECONDY  update  HA2 
update  LAST-OR  update  SUM-OUTPUT  update  CARRY-OUTPUT 
subsystem  HAl  is  controls: 

HAl-ANDl,  HA1-AND2,  HA1-AND3,  HAl-OR  ix^orts:  exports: 
initi2d.ize  procedure:  update  procedure: 
update  HAl-ANDl  update  HA1-AND2  update  HA1-AND3 
update  HAl-OR 
comp-x:  577  cony-y:  65 
subsystem  HA2  is  controls: 

HA2-AND1,  HA2-AND2,  HA2-AND3,  HA2-0R  imports:  exports: 
initialize  procedure:  update  procedure: 
update  HA2-AND1  update  HA2-AND2  update  BA2-AND3 
update  HA2-0R 
coiq>-x:  452  comp-y:  240 

or-gate  LAST-OR  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  comp-x:  120  comp-y:  100 
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C.S  DECODERl  Application 

This  application  provides  a  test  of  a  “decoder”  primitive  by  providing  3  input  switches  and 
8  output  LEDs. 

application  definition  DECODERl 
execution-mode:  NON-EVENT-DRIVEN-SEQUEMTIAL 
switch  X-IN  delay:  0  not  debounced  manufacturer:  "  " 
position:  OFF  coo^-x:  92  comp-y:  400 
switch  Y-IN  delay:  0  not  debounced  manufacturer:  "  " 
position:  OFF  con^-x:  99  con^-y:  576 
switch  Z-IN  delay:  0  not  debounced  manufacturer:  "  ” 
position:  ON  coo^-x:  93  comp-y:  218 


led  NO  manufacturer: 

tl 

II 

color : 

RED 

conp-x: 

628 

conp-y : 

415 

led  Ml  manufacturer: 

II 

II 

color : 

RED 

comp-x: 

630 

conp-y : 

495 

led  N2  manufacturer: 

II 

II 

color : 

RED 

comp-x: 

632 

conp-y: 

575 

led  M3  manufacturer: 

It 

II 

color : 

RED 

comp-x: 

632 

conp-y : 

656 

led  N4  manufacturer: 

II 

II 

color: 

RED 

comp-x: 

626 

conp-y : 

335 

led  N5  manufacturer: 

II 

It 

color : 

RED 

coap-x: 

623 

conp-y: 

256 

led  M6  manufacturer: 

II 

It 

color : 

RED 

conp-x: 

626 

conp-y : 

178 

led  M7  manufacturer: 

It 

It 

color : 

RED 

conp-x: 

629 

conp-y : 

99 

decoder  A-DECODER  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  con5>-x:  353  comp-y:  388 


subsystem  DO-DECODE  is  controls: 

X-IN,  y-IN,  Z-IN,  MO,  Ml,  M2,  M3,  M4, 

M5,  M6,  M7,  A-DECODER 
imports: 

IN3  SIGNAL  BOOLEAN  A-DECODER  (  OUTl  OO-DECODE  Z-IN 
)  iiq>ort-path:  (  DO-DECODE  )  io^ort-owner :  DO-DECODE 
IN2  SIGNAL  BOOLEAN  A-DECODER  (  OUTl  DO-DECODE  Y-IN 
)  import -path:  (  DO-DECODE  }  is^ort-owner :  DO-DECODE 
INI  SIGNAL  BOOLEA'  \-DEC0DER  (  OUTl  DO-DECODE  X-IN 
)  io^ort-path:  (  OO-DECODE  )  io^ort-owner :  DO-DECODE 
INI  SIGNAL  BOOLEAN  N7  (  N7  DO-DECODE  A-DECODER 

)  import -path:  (  DO-DECODE  )  import-owner:  DO-DECODE 
INI  SIGNAL  BOOLEAN  N6  (  N6  DO-DECODE  A-DECODER 

)  import -path:  (  DO-DECODE  }  import-owner:  DO-DECODE 
INI  SIGNAL  BOOLEAN  M5  (  N5  DO-DECODE  A-DECODER 

)  iiq>ort-path:  (  DO-DECODE  }  import-owner:  DO-DECODE 
INI  SIGNAL  BOOLEAN  N4  (  N4  DO-DECODE  A-DECODER 

)  i]q>ort-path:  (  OO-DECODE  }  import-owner:  DO-DECODE 
INI  SIGNAL  BOOLEAN  M3  (  M3  DO-DECODE  A-DECODER 

)  insert -path:  (  DO-DECODE  )  import-owner:  DO-DECODE 
INI  SIGNAL  BOOLEAN  M2  (  M2  DO-DECODE  A-DECODER 

)  import -path:  (  DO-DECODE  )  iisport-owner:  DO-DECODE 
INI  SIGNAL  BOOLEAN  Ml  (  Ml  DO-DECODE  A-DECODER 

)  inport-path:  (  DO-DECODE  )  import-owner:  DO-DECODE 
INI  SIGNAL  BOOLEAN  MO  (  MO  DO-DECODE  A-DECODER 

)  inport-path:  (  DO-DECODE  )  import-owner:  DO-DECODE 
exports : 

M7  SIGNAL  BOOLEAN  A-DECODER 
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export -path:  (  OO-DECOOE  )  ezport-ovner :  DO-DECODE 
N6  SIGNAL  BOOLEAN  A-DECODER 

export -path:  (  DO-DECODE  )  export-owner:  DO-DECODE 
MS  SIGNAL  BOOLEAN  A-DECODER 

export-path:  (  DO-DECODE  )  export-owner:  DO-DECODE 
N4  SIGNAL  BOOLEAN  A-DECODER 

export -path:  (  DO-DECODE  )  export-owner:  DO-DECODE 
N3  SIGNAL  BOOLEAN  A-DECODER 

export-path:  (  DO-DECODE  )  export-owner:  DO-DECODE 
M2  SIGNAL  BOOLEAN  A-DECODER 

export -path:  (  DO-DECODE  )  export-owner:  DO-DECODE 
Ml  SIGNAL  BOOLEAN  A-DECODER 

export-path:  (  DO-DECODE  )  export-owner:  DO-DECODE 
MO  SIGNAL  BOOLEAN  A-DECODER 

export -path:  (  DO-DECODE  )  export-owner:  DO-DECODE 
OUTl  SIGNAL  BOOLEAN  Z-IN 

export -path:  (  DO-DECODE  )  export-owner:  DO-DECODE 
OUTl  SIGNAL  BOOLEAN  Y-IN 

export-path:  (  DO-DECODE  )  export - owner :  DO-DECODE 
OUTl  SIGNAL  BOOLEAN  X-IN 

export-path:  (  DO-DECODE  )  export-owner:  DO-DECODE 
initialize  procedure:  update  procedure: 
update  X-IN  update  Y-IN  update  Z-IN  update  A-DECODER 
update  MO  update  Ml  update  M2  update  M3  update  M4  update  MS 
update  M6  update  M7 

application  DECODERl  is  controls:  DO-DECODE 
update  procedure:  update  DO-DECODE 


C.4  ADD-AND-DECODE  Application 

This  application  tests  the  combination  of  an  adder  and  a  decoder.  The  adder  is  a  subsystem 
composed  of  2  half-adder  subsystems,  each  composed  out  of  “and"  gates,  “or”  gates,  and  “not” 
gates.  The  decoder  is  also  a  subsystem,  composed  of  “and”  gates  and  “not”  gates. 

application  definition  ADD-AND-DECODE 
execution-mode:  NON-EVENT-DRIVEN-SEQUENTIAL 
application  ADD-AND-DECODE  is  controls: 

DRIVE-DECODERl ,  AODERl  update  procedure: 
update  ADDERl  update  DRIVE-DECODERl 
switch  SWITCH-NULL  delay:  0  not  debounced  manufacturer:  "  " 
position:  OFF  conp~x:  360  coiq>-y:  100 
subsystem  DRIVE-DECODERl  is  controls: 

SWITCH-NULL,  MO,  Ml,  M2,  M3,  M4,  MS,  M6, 

M7,  DECODERl 
imports: 

IN2  SIGNAL  BOOLEAN  AND-N7-B 

(  OUTl  DRIVE-DECODERl  SWITCH-NULL 

)  iiq>ort-path:  (  DRIVE-DECODERl  DECODERl  )  import-owner: 

DECODERl 
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im  SIGHAL  BOOLEAX  AXD-MT-B  (  imi  DEC(U>EB1  AID-MT-i 
)  i]q>ort-path:  (  ORIVE-OECOOm  OECQDEBl  )  iaport-onar : 
DECOOERl 

IN2  SIGNAL  BOOLEAN  AND-M7-A  (  OUTl  AOOERl  LAST-OK 

)  ioport-path:  (  DRIVE-DECOOERl  DECODEBl  )  iaport-ov&ar : 
DECOOERl 

INI  SIGNAL  BOOLEAN  AND-H7-A  (  OOTl  eA2  HA2-0R 

)  inport-path:  (  DRIVE-DECODERl  DECOOERl  )  iaport-otmar: 
DECOOERl 

IN2  SIGNAL  BOOLEAN  AND-M6-B 

(  OUTl  DRIVE-DECODERl  SWITCH-NULL 

)  inport-path:  (  DRIVE-DECODERl  DECOOERl  )  inport-ovnor : 
DECOOERl 

INI  SIGNAL  BOOLEAN  AND-M6-B  (  OUTl  DECOOERl  AND-N6-A 
}  iiiq>ort-path:  (  DRIVE-DECODERl  DECOOERl  )  inport-ovnar : 
DECOOERl 

IN2  SIGNAL  BOOLEAN  AND-N6-A  (  OUTl  AODERl  LAST-OR 

)  i]q>ort-path:  (  DRIVE-DECODERl  DECOOERl  )  inport-ovnar: 
DECOOERl 

INI  SIGNAL  BOOLEAN  AND-M6-A  (  OUTl  DECOOERl  NOT-Z 

)  iiport-path:  (  DRIVE-DECODERl  DECOOERl  )  inport-ovnar: 
DECOOERl 

IN2  SIGNAL  BOOLEAN  AND-MS-B 

(  OUTl  DRIVE-DECODERl  SWITCH-NULL 

)  inport-path:  (  DRIVE-DECODERl  DECOOERl  )  inport-ovnar: 
DECOOERl 

INI  SIGNAL  BOOLEAN  AND-M6-B  (  OUTl  DECOOERl  AND-N5-A 
)  inport-path:  (  DRIVE-DECODERl  D&I^DERl  )  inport-ovnar: 
DECOOERl 

IN2  SIGNAL  BOOLEAN  AND-M5-A  (  OUTl  DECOOERl  NOT-Y 

)  inport-path:  (  DRIVE-DECODERl  DECOOERl  )  inport-ovnar: 
DECOOERl 

INI  SIGNAL  BOOLEAN  AND-N5-A  (  OUTl  HA2  HA2-0R 

)  inport-path:  (  DRIVE-DECOOERl  DECOOERl  )  inport-ovnar: 
OECODERl 

IN2  SIGNAL  BOOLEAN  AND-N4-B 

(  OUTl  DRIVE-DECODERl  SWITCH-NULL 

)  inport-path:  (  DRIVE-DECODERl  OECODERl  >  inport-ovnar: 
DECOOERl 

INI  SIGNAL  BOOLEAN  AND-N4-B  (  OUTl  DECOOERl  AND-N4-A 
)  inport-path:  (  DRIVE-DECODER!  DECOOERl  )  inport-ovnar: 
DECOOERl 

IN2  SIGNAL  BOOLEAN  AND-M4-A  (  OUTl  OECODERl  NOT-Y 
)  inport-path:  (  DRIVE-DECODERl  DKODERl  )  inport-ovnar: 
DECOOERl 

INI  SIGNAL  BOOLEAN  AND-N4-A  (  OUTl  DECOOERl  NOT-Z 

)  inport-path:  (  DRIVE-DECODERl  DECOOERl  )  inport-ovnar: 
OECODERl 

IN2  SIGNAL  BOOLEAN  AND-M3-B  (  OUTl  DECOOERl  NOT-X 
)  inport-path:  (  DRIVE-DECODERl  DECOOERl  )  inport-ovnar: 
DECOOERl 
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INI  SIGNAL  BOOLEAN  AND-N3-B  (  OOTl  DECOOERi  AND-M3-A 
}  liqport-path:  (  DRIVE-DECOOEBl  DECODBRl  )  ioport-OBiier : 

DECOOERI 

IN2  SIGNAL  BOOLEAN  AND-M3-A  (  OOTl  ADOERl  LAST-OR 

)  iiq>ort~path:  (  DRIVE-DECOOERl  DECOOERI  )  iaport-oimar : 

DECODERl 

INI  SIGNAL  BOOLEAN  AND-M3-A  (  OOTl  HA2  HA2-0R 

)  inport-patR:  (  DRIVE-DECODERl  DECODERl  )  iaport-omar: 

DECODERl 

IN2  SIGNAL  BOOLEAN  AND-M2-B  (  OOTl  DECODERl  NOT-X 

)  import-path:  (  DRIVE-DECODERl  DECODERl  )  iaport-ovnar : 

DECODERl 

INI  SIGNAL  BOOLEAN  AND-N2-B  <  OOTl  DECOOERI  AND-N2-A 
}  iiq>ort-path:  (  DRIVE-DECODERl  DECODERl  )  import-ovnor : 

DECODERl 

IN2  SIGNAL  BOOLEAN  AND-N2-A  (  OOTl  ADDERl  LAST-OR 

)  ioport-path:  (  DRIVE-DECODERl  DECODERl  )  ioqport-otmor : 

DECODERl 

INI  SIGNAL  BOOLEAN  AND-M2-A  (  OOTl  DECODERl  NOT-Z 

)  io^ort-path:  (  DRIVE-DECODERl  DECODERl  )  iaport-omer: 

DECODERl 

IN2  SIGNAL  BOOLEAN  AND-Ml-B  (  OOTl  DECODERl  NOT-X 

)  iaport-path:  (  DRIVE-DECODERl  DECODERl  )  import-oimar : 

DECOOERI 

INI  SIGNAL  BOOLEAN  AND-Nl-B  (  OOTl  DlTCODERl  AND-Ml-A 
)  import-path:  (  DRIVE-DECOOERl  DECOOERI  )  import-omar: 

DECOOERI 

IN2  SIGNAL  BOOLEAN  AND-Ml-A  (  OOTl  DECODERl  NOT-Y 

)  in^ort-path:  (  DRIVE-DECODERl  DECODERl  )  import-oraer : 

DECODERl 

INI  SIGNAL  BOOLEAN  AND-Ml-A  (  OOTl  HA2  HA2-0R 

)  iiport-path:  (  DRIVE-DECODERl  DECODERl  )  inport-ovner : 

DECODERl 

IN2  SIGNAL  BOOLEAN  AND-NO-B  (  OOTl  DECODERl  NOT-X 

)  inport-path:  (  DRIVE-DECOOERl  DECODERl  }  import -ovner : 

DECODERl 

INI  SIGNAL  BOOLEAN  AND-MO-B  (  OOTl  DECODERl  AND-MO-A 
}  inport-path:  (  DRIVE-DECODERl  DECODERl  )  import-omer: 

DECODERl 

IN2  SIGNAL  BOOLEAN  AND-NO-A  (  OOTl  DECODERl  NOT-Y 

)  inport-path:  (  DRIVE-DECODERl  DECODERl  )  inport-oonar : 

DECODERl 

INI  SIGNAL  BOOLEAN  AND-NO-A  (  OOTl  DECODERl  NOT-Z 
)  import-path:  (  DRIVE-DECODERl  DECODERl  )  inport-omar : 

DECODERl 

INI  SIGNAL  BOOLEAN  NOT-Z  (  OOTl  EA2  HA2-0R 

)  inport-path:  (  DRIVE-DECODERl  DECODERl  }  inport-omar : 

DECODERl 

INI  SIGNAL  BOOLEAN  NOT-Y  (  OOTl  ADDERl  LAST-OR 

)  inport-path:  (  DRIVE-DECODERl  DECODERl  )  inport-ovnar : 

DECODERl 
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IMl  SI6MAL  BOOLEAM  HOT-X  (  OUTl  DRIVE-DECOOERI  SVITCH-NULL 
)  ia^ort-patb:  (  DRIVE-DECODERI  DECOOERl  )  iBi>ort-om«r : 

OECOOERl 

INI  SIGNAL  BOOLEAN  M7  (  OUTl  OECODERl  AND-N7-B 
)  iiq>ort-path :  (  DRIVE-DECODERI  )  iaport-o«n*r : 

DRIVE-DECODERI 

INI  SIGNAL  BOOLEAN  M6  (  OUTl  DECODERl  AND-M6-B 
)  import-path:  (  DRIVE-DECODERI  )  iaport-ovnar: 

DRIVE-DECODERI 

INI  SIGNAL  BOOLEAN  MS  (  OUTl  DECODERl  AND-N5-B 
}  in^ort-path:  (  DRIVE-DECODERI  )  inport-omar : 

DRIVE-DECODERI 

INI  SIGNAL  BOOLEAN  M4  (  OUTl  DECODERl  AND-M4-B 
)  inport-path:  (  DRIVE-DECODERI  )  iaport-ovnar : 

DRIVE-DECODERI 

INI  SIGNAL  BOOLEAN  N3  (  OUTl  DECODERl  AND-M3-B 
)  iaport-path:  (  DRIVE-DECODERI  )  isport-ovnar : 

DRIVE-DECODERI 

INI  SIGNAL  BOOLEAN  H2  (  OUTl  DECOOERl  AND-M2-B 
)  inport-path:  (  DRIVE-DECODERI  )  inport-ovnar : 

DRIVE-DECODERI 

INI  SIGNAL  BOOLEAN  Ml  (  OUTl  DECODERl  AND-Ml-B 
}  import-path:  (  DRIVE-DECODERI  )  import-omar: 

DRIVE-DECODERI 

INI  SIGNAL  BOOLEAN  NO  (  OUTl  DECODERl  AND-NO-B 
)  import-path:  (  DRIVE-DECODERI  )  ioport-omar: 

DRIVE-DECODERI 

azports : 

OUTl  SIGNAL  BOOLEAN  AND-N7-B 


azport-path:  (  DRIVE-DECODERI  DECODERl  )  azport-ovnar : 


DECODERl 

OUTl  SIGNAL  BOOLEAN  AND-N7-A 

azport-path:  (  DRIVE-DECODERI  DECODERl 
DECODERl 

OUTl  SIGNAL  BOOLEAN  AND-N6-B 

azport-path:  (  DRIVE-DECODERI  DECODERl 
DECODERl 

OUTl  SIGNAL  BOOLEAN  AND-N6-A 

azport-path:  (  DRIVE-DECODERI  DECODERl 
DECODERl 

OUTl  SIGNAL  BOOLEAN  AND-N5-B 

azport-path:  (  DRIVE-DECODERI  DECODERl 
DECODERl 

OUTl  SIGNAL  BOOLEAN  AND-MS-A 

azport-path:  (  DRIVE-DECODERI  DECODERl 
DECODERl 

OUTl  SIGNAL  BOOLEAN  AND-M4-B 

azport-path:  (  DRIVE-DECODERI  DECODERl 
DECODERl 

OUTl  SIGNAL  BOOLEAN  AND-M4-A 

azport-path:  (  DRIVE-DECODERI  DECODERl 


)  azport-ovnar : 


)  azport-ownar : 


)  azport-oimar: 


)  azport-ovnar : 


}  azport-omar: 


)  azport-ovnar: 


}  azport-ovnar: 
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DECOOERl 

OUTl  SIGNAL  BOOLEAN  AND-M3-B 
•zport-path:  (  DRIVE-DECOOERl  DECODERl  )  ezport-o«x«r : 
DECOOERl 

OOTl  SIGNAL  BOOLEAN  AND-M3-A 

axport-path:  (  DRIVE-DECOOERl  O^ODERl  )  export -oimar: 
DECOOERl 

OUTl  SIGNAL  BOOLEAN  AND-N2-B 

•xport-path:  (  DRIVE-DECOOERl  DKOOERl  )  azport-omar: 
DECODERl 

OUTl  SIGNAL  BOOLEAN  AND-M2-A 

export-path:  (  DRIVE-DECODERl  DECODERl  )  export-owner: 
DECODERl 

OUTl  SIGNAL  BOOLEAN  AND-Ml-B 

export-path:  (  DRIVE-DECOOERl  DECODERl  )  export-owner: 
DECODERl 

OUTl  SIGNAL  BOOLEAN  AND-Nl-A 

export-path:  (  DRIVE-DECODERl  DECODERl  )  export-owner: 
DECODERl 

OUTl  SIGNAL  BOOLEAN  AND-MO-B 

export-path:  (  DRIVE-DECODERl  D^ODERl  )  export-owner: 
DECODERl 

OUTl  SIGNAL  BOOLEAN  AND-MO-A 
export-path:  (  DRIVE-DECOOERl  DECODERl  )  export-owner: 
DECODERl 

OUTl  SIGNAL  BOOLEAN  NOT-Z 

export -path:  (  DRIVE-DECODERl  DECODERl  }  export-owner: 
DECODERl 

OUTl  SIGNAL  BOOLEAN  NOT-Y 

export-path:  (  DRIVE-DECODERl  DECOOERl  )  export-owner: 
DECODERl 

OUTl  SIGNAL  BOOLEAN  NOT-X 

export-path:  (  DRIVE-DECOOERl  DECODERl  )  export-owner: 
DECODERl 

OUTl  SIGNAL  BOOLEAN  SWITCH-NULL 

export-path:  (  DRIVE-DECODERl  )  export-owner:  DRIVE-DECODERl 
initieQize  procedure:  update  procedure: 
update  SWITCH-NULL  update  DECODERl  update  MO  update  Ml 

update  N2  update  N3  update  N4  update  NS  update  H6  update  N7 
and-gate  AND-MO-A  delay:  0  not  mil-apec  manufacturer:  "  " 
power  level:  0.0  comp-x:  697  conp-y:  753 
and-gate  AND-NO-B  delay:  0  not  mil-apec  manufacturer:  "  " 
power  level:  0.0  comp-x:  921  conp-y:  762 
and-gate  AND-Nl-A  delay:  0  not  mil-apec  manufacturer:  "  " 
power  level:  0.0  comp-x:  599  comp-y:  664 
and-gate  AND-Ml-B  delay;  0  not  mil-apec  manufacturer:  "  " 
power  level:  0.0  conp-x:  924  conp-y:  665 
and-gate  AMD-M2-A  delay:  0  not  mil-apec  manufacturer:  "  " 
power  level:  0.0  comp-x:  602  comp-y:  574 
and-gate  AND-M2-B  delay:  0  not  mil-apec  manufacturer:  "  " 
power  level:  0.0  conp-x:  925  comp-y:  575 
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and-gat*  AND-M3-A  dalay:  0  not  nil-apac  manuf acturar : 

povar  laval:  0.0  coag>-z:  601  eoa^-y;  484 
and-gata  iMD-N3-B  dalay:  0  not  mll-spac  aannlacturax :  '*  " 
povar  laval:  0.0  coop-z:  926  conp-y:  486 
and-gata  AIID-M4-A  dalay:  0  not  mil-apac  manulacturar :  "  " 
povar  laval:  0.0  conp-z:  604  coop-y:  391 
and-gata  AND-M4-B  dalay:  0  not  mil-apac  manuf actnrar :  "  " 
povar  laval:  0.0  conp-z:  928  conp-y:  401 
and-gata  AND-MS-A  dalay:  0  not  mil-apac  mannf acturar :  "  " 
povar  laval:  0.0  comp-z:  608  conp-y:  299 
and-gata  AND-HE-B  dalay:  0  not  mil-apac  manuf acturar:  "  " 
povar  laval:  0.0  conp-z:  929  conp-y:  314 
and-gata  A1ID-M6-A  dalay:  0  not  mil-apac  manuf acturar :  "  " 
povar  laval:  0.0  conp-z:  615  conp-y:  206 
and-gata  AMD-M6-B  dalay:  0  not  mil-apac  manuf acturar :  "  " 
povar  laval:  0.0  conp-z:  928  conp-y:  217 
and-gata  AND-M7-A  dalay:  0  not  mil-apac  manuf acturar:  “  " 
povar  laval:  0.0  conp-z:  616  conp-y:  93 
and-gata  AND-M7-B  dalay:  0  not  mil-apac  manuf acturar :  "  " 
povar  laval:  0.0  conp-z:  923  conp-y:  106 
lad  MO  manuf  acturar:  "  "  color:  RED  conp-z:  240  conp-y:  400 

led  HI  manufacturer:  "  '*  color:  RED  conp-z:  240  conp-y:  300 

led  M2  manuf acturar :  "  "  color:  RED  conp-z:  240  conp-y:  200 

led  M3  manuf acturar :  "  "  color:  RED  conp-z:  240  conp-y:  100 

led  M4  manuf acturar :  "  "  color:  RED  conp-z:  120  conp-y:  400 

lad  MS  manuf  acturar :  '*  "  color:  RED  conp-z:  120  conp-y:  300 

lad  M6  manuf acturar:  "  "  color:  RED  conp-z:  120  conp-y:  200 

lad  N7  manuf acturar :  "  "  color:  RED  conp-z:  120  conp-y:  100 

not-gata  NOT-X  dalay:  0  not  mil-spac  manuf acturar:  "  " 
povar  laval:  0.0  conp-z:  733  conp-y:  601 
not-gata  NOT-Y  dalay:  0  not  mil-spac  manufacturer:  "  " 
povar  laval:  0.0  conp-z:  208  conp-y:  505 
not-gata  NOT-Z  dalay:  0  not  mil-spac  manufacturer:  "  " 
povar  laval:  0.0  conp-z:  203  conp-y:  673 
subsystem  DECODERl  is  controls: 

MOT-X,  NOT-Y,  MOT-Z,  AHD-MO-A,  AND-MO-B,  AND-Ml-A, 

AND-Ml-B,  AND-M2-A,  AND-M2-B,  AND-M3-A.  AND-M3-B,  AND-M4-A, 
AND-M4-B,  AND-M5-A,  AND-M5-B,  AND-M6-A,  AND-M6-B,  AND-M7-A, 
AND-M7-B 

imports:  exports:  initialize  procedure:  update  procedure: 
update  NOT-X  update  NOT-Y  update  NOT-Z  update  AND-NO-A 
update  AND-MO-B  update  AND-Ml-A  update  AND-Ml-B 
update  AND-H2-A  update  AND-M2-B  update  AND-H3-A 
update  AND-M3-B  update  AND-M4-A  update  AND-M4-B 
update  AND-M5-A  update  AND-N5-B  update  AND-M6-A 
update  AND-M6-B  update  AND-M7-A  update  AND-M7-B 
conp-z:  446  conp-y:  259 
subsystem  ADDERl  is  controls: 

HAl,  HA2,  SWITCH-IADDEND,  SW1TCH-2ADDEMD,  SHITCH-3ADDEND . 
NOT-FIRSTX,  NOT-FIRSTY,  NOT-SECONDX,  NOT-SECONDY, 
SOM-OOTPUT,  CARRY-OOTPDT,  LAST-OR 
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ioports: 

INI  SIGNAL  BOOLEAN  HAl-ANDl  (  OOTl  ADDERl  SWITCH- 1 ADDEND 
)  iiq>ort-patli:  (  ADDERl  EAl  )  Inqport-oBntr :  HAl 
IN2  SIGNAL  BOOLEAN  HAl-ANDl  (  OOTl  ADDERl  NOT-FIRSTY 
)  inport -path:  (  ADDERl  HAl  )  ioport-otmar :  HAl 
INI  SIGNAL  BOOLEAN  HA1-AND2  (  OOTl  ADDERl  NOT-FIRSTX 
)  inport-path:  (  ADDERl  HAl  )  inport-oimar :  HAl 
IN2  SIGNAL  BOOLEAN  HA1-AND2  (  OOTl  ADDERl  SWITCH- 2ADDEND 
)  inport-path:  (  ADDERl  HAl  )  inport-otmar :  HAl 
INI  SIGNAL  BOOLEAN  BA1-AND3  (  OOTl  ADDERl  SWITCH- 1 ADDEND 
)  inport-path:  (  ADDERl  HAl  )  inport-ownar :  HAl 
IN2  SIGNAL  BOOLEAN  HA1-AND3  (  OOTl  ADDERl  SWITCH- 2ADDEND 
)  inport-path:  (  ADDERl  HAl  )  inport-oimar :  HAl 
INI  SIGNAL  BOOLEAN  HAl-OR  (  OOTl  HAl  HAl-ANDl 
)  inport-path:  (  ADDERl  HAl  )  inport-omar:  HAl 
IN2  SIGNAL  BOOLEAN  HAl-OR  (  OOTl  HAl  HA1-AND2 
)  import-path:  (  ADDERl  EAl  )  ii^ort-oniar :  HAl 
INI  SIGNAL  BOOLEAN  HA2-AND1  (  OOTl  HAl  HAl-OR 
)  import-path:  (  ADDERl  RA2  )  inport-ovnar :  HA2 
IN2  SIGNAL  BOOLEAN  BA2-AND1  (  OOTl  ADDERl  NOT-SECONDY 
)  import -path:  (  ADDERl  HA2  )  inport-ownar:  HA2 
INI  SIGNAL  BOOLEAN  HA2-AND2  (  OOTl  ADDERl  NOT-SECONDX 
)  inport-path:  (  ADDERl  HA2  )  inport-ownar:  HA2 
IN2  SIGNAL  BOOLEAN  BA2-AND2  (  OOTl  ADDERl  SHITCH-3ADDEND 
)  inport-path:  (  ADDERl  HA2  )  inport-ownar:  HA2 
INI  SIGNAL  BOOLEAN  BA2-AND3  (  OOTl  HAl  HAl-OR 
)  inport-path:  (  ADDERl  RA2  )  iiq>ort-ownar:  HA2 
IN2  SIGNAL  BOOLEAN  BA2-AND3  (  OOTl  ADDERl  SWITCH-3ADDEND 
)  inport-path:  (  ADDERl  HA2  )  inport-ownar:  HA2 
INI  SIGNAL  BOOLEAN  BA2-0R  (  OOTl  EA2  HA2-AND1 
)  inport-path:  (  ADDERl  HA2  )  inport-ownar:  HA2 
IN2  SIGNAL  BOOLEAN  HA2-0R  (  OOTl  HA2  HA2-AND2 
)  inport-path:  (  ADDERl  HA2  )  inport-ownar:  HA2 
IN2  SIGNAL  BOOLEAN  UST-OR  (  OOTl  HAl  HA1-AND3 
)  inport-path:  (  ADDERl  )  inport-ownar:  ADDERl 
INI  SIGNAL  BOOLEAN  UST-OR  (  OOTl  HA2  HA2-AND3 
)  inport-path:  (  ADDERl  )  inport-ownar:  ADDERl 
INI  SIGNAL  BOOLEAN  CARRY-OOTPOT  (  OOTl  ADDERl  LAST-OR 
)  inport-path:  (  ADDERl  }  inport-ownar:  ADDERl 
INI  SIGNAL  BOOLEAN  SON-OOTPOT  (  OOTl  HA2  HA2-0R 
)  inport-path:  (  ADDERl  }  inport-ownar:  ADDERl 
INI  SIGNAL  BOOLEAN  NOT-SECONDY  (  OOTl  ADDERl  SWITCH-3ADDEND 
)  inport-path:  (  ADDERl  )  inport-ownar:  ADDERl 
INI  SIGNAL  BOOLEAN  NOT-SECONDX  (  OOTl  HAl  HAl-OR 
)  inport-path:  (  ADDERl  )  inport-ownar:  ADDERl 
INI  SIGNAL  BOOLEAN  NOT-FIRSTY  (  OOTl  ADDERl  SWITCH-2ADDEND 
)  inport-path:  (  ADDERl  )  inport-ownar:  ADDERl 
INI  SIGNAL  BOOLEAN  NOT-FIRSTX  (  OOTl  ADDERl  SWITCH- 1 ADDEND 
)  inport -path:  (  ADDERl  )  inport-ownar:  ADDERl 
azports: 

OOTl  SIGNAL  BOOLEAN  HAl-ANDl 
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•zport-path:  (  ADDERl  HAl  )  •xport-o«a«r :  Hll 
OUTl  SIGNAL  BOOLEAN  HA1-AND2 

export-path:  (  AODERl  HAl  )  export-owner:  HAl 
OUTl  SIGNAL  BOOLEAN  HA1-AND3 

export -path:  (  ADOERl  HAl  )  export-owner:  HAl 
OUTl  SIGNAL  BOOLEAN  HAl-OR 

export-path:  (  ADDERl  HAl  )  export-owner:  HAl 
OUTl  SIGNAL  BOOLEAN  HA2-AND1 

export-path:  (  ADOERl  HA2  )  ejqwrt - owner :  BA2 
OUTl  SIGNAL  BOOLEAN  HA2-AND2 

export -path:  (  AODERl  HA2  )  export-owner:  HA2 
OUTl  SIGNAL  BOOLEAN  HA2-AND3 

export-path:  (  AODERl  HA2  )  export-owner:  HA2 
OUTl  SIGNAL  BOOLEAN  HA2-0R 

export -path:  (  AODERl  HA2  )  export-owner:  HA2 
OUTl  SIGNAL  BOOLEAN  UST-OR 

export-path:  (  ADOERl  )  export-owner:  AODERl 
OUTl  SIGNAL  BOOLEAN  NOT-SECONDY 

export-path:  (  AODERl  )  export-owner:  ADDERl 
OUTl  SIGNAL  BOOLEAN  NOT-SECONDX 

export-path:  C  AODERl  )  export-owner:  ADDERl 
OUTl  SIGNAL  BOOLEAN  NOT-FIRSTY 

export-path:  (  ADDERl  )  export-owner:  AODERl 
OUTl  SIGNAL  BOOLEAN  NOT-FIRSTX 

export -path:  (  AODERl  )  export-owner:  AODERl 
OUTl  SIGNAL  BOOLEAN  SWITCH- 3ADDEHD 

export-path:  (  AODERl  )  export-owner:  ADDERl 
OUTl  SIGNAL  BOOLEAN  SWITCH-2ADDEND 

export-path:  (  AODERl  )  export-owner:  ADDERl 
OUTl  SIGNAL  BOOLEAN  SWITCH- 1 ADDEND 

export -path:  (  ADOERl  )  export-owner:  ADDERl 
initialize  procedure:  update  procedure: 
update  SWITCH-IAODEND  update  SWITCH-2ADDEND 

update  SWITCH-3ADDEND  update  NOT-FIRSTX  update  NOT-FIRSTY 
update  HAl  update  NOT-SECONDX  update  NOT-SECONDY  update  HA2 
update  LAST-OR  update  SUM-OUTPUT  update  CARRY-OUTPUT 
and-gate  HAl-ANDl  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  comp-x:  121  con^-y:  90 
and-gate  HA1-AND2  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  coiq>-x:  124  coEq)-y:  199 
and-gate  HA1-AND3  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  comp-x:  119  con5>-y:  305 
or-gate  HAl-OR  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  comp-x:  241  comp-y:  139 
subsystem  HAl  is  controls: 

HAl-ANDl,  HA1-AND2,  HA1-AND3,  HAl-OR  imports:  exports: 
initialize  procedure:  update  procedure: 
update  HAl-ANDl  update  HA1-AND2  update  HA1-AND3 
update  HAl-OR 
conp-x:  449  conp-y:  334 

and-gate  HA2-AND1  delay:  0  not  mil-spec  manufacturer:  "  " 
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power  level:  0.0  conp-z:  116  conp-y:  72 
axid-gate  HA2-AND2  delay:  0  not  mil-spec  manulactorer : 

power  level:  0.0  cogq>-x:  118  conp-y:  193 
and-gate  HA2-iND3  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  coiq>-z:  118  cosp-y:  306 
or-gate  HA2-0R  delay:  0  not  mil-spec  manufacturer:  ”  " 
power  level:  0.0  conp-z:  227  coiq>-y:  131 
subsystem  BA2  is  controls: 

HA2-AND1.  HA2-AI1D2,  Hi2-iND3.  Hi2-0R  io^rts:  exports: 
initialize  procedure:  update  procedure: 
update  HA2-iNDl  update  Ei2-AND2  update  Hi2-iND3 
update  HA2-0R 
comp-x:  451  coo^-y:  111 

or-gate  LAST-OR  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  comp-x:  92  conp-y:  387 
not-gate  NOT-FIRSTI  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  conp-x:  245  conp-y:  108 
not-gate  NOT-FIRSTY  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  conp-x:  240  coop-y:  200 
not-gate  NOT-SECONDX  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  comp-x:  89  conp-y:  486 
not-gate  NOT-SECONDY  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  comp-x:  242  conp-y:  298 
led  SUM-OUTPUT  manufacturer:  "  "  color:  RED  conp-x:  227 
conp-y:  480 

led  CARRY-OUTPUT  manufacturer:  "  "  color:  RED  conp-x:  233 
conp-y:  389 

switch  SWITCH- 1 ADDEND  delay:  0  not  debounced 
manufacturer:  "  "  position:  ON  conp-x:  113  conp-y:  104 
switch  SWITCH- 2ADDEND  delay:  0  not  debounced 
manufacturer:  "  "  position;  ON  conp-x:  105  conp-y:  200 
switch  SWITCH-3A0DE3ID  delay;  0  not  debounced 
manufacturer:  "  "  position:  OFF  conp-x:  103  conp-y:  291 


C.5  ADD-AND-DECODE2  Application 

This  application  is  similar  to  the  ADD-AND-DECODE  application  mentioned  above,  except 
the  decoder  subsystem  is  implemented  aa  a  decoder  with  output  (i.e.,  the  LEDs  have  been  moved 
down  under  the  control  of  the  decoder  subsystem). 

application  definition  ADD-AND-DEC(H)E2 
execution-mode :  NON-EVENT-DRIVEN-SEQUENTIAL 
application  ADD-AND-DEC0DE2  is  controls: 

DRIVE-DECODER,  ADDER3  update  procedure: 
update  ADDER3  update  DRIVE-DECODER 
switch  SWITCH-NULL  delay:  0  not  debounced  manufacturer:  "  " 
position:  OFF  conp-x:  120  conp-y:  100 
subsystem  DRIVE-DECODER  is  controls: 

SWITCH-NULL,  DECODER-WITH-OUTPUT 
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uq>orts: 

INI  SIGNAL  BOOLEAN  N7  (  OUTl  DECODER-WITH-OUTPUT  AND-M7-B 
)  ijq>ort-path:  (  DRIVE-DECODER  DECODER-WITH-OUTPUT 
)  inqport-ownar :  DECODER-WITH-OUTPUT 
INI  SIGNAL  BOOLEAN  M6  (  OUTl  DECODER-WITH-OUTPUT  AND-M6-B 
)  import-path:  (  DRIVE-DECODER  DECODER-WITH-OUTPUT 
)  import-ownar :  DECODER-WITH-OUTPUT 
INI  SIGNAL  BOOLEAN  M5  <  OUTl  DECODER-WITH-OUTPUT  AND-M5-B 
)  import -path:  (  DRIVE-DECODER  DECODER-WITH-OUTPUT 
)  import-ownar:  DECODER-WITH-OUTPUT 
INI  SIGNAL  BOOLEAN  M4  (  OUTl  DECODER-WITH-OUTPUT  AND-M4-B 
)  in5)ort-path:  (  DRIVE-DECODER  DECODER-WITH-OUTPUT 
)  import-ownar:  DECODER-WITH-OUTPUT 
INI  SIGNAL  BOOLEAN  M3  (  OUTl  DECODER-WITH-OUTPUT  AND-N3-B 
)  import -path:  <  DRIVE-DECODER  DECODER-WITH-OUTPUT 
)  import-ownar:  DECODER-WITH-OUTPUT 
INI  SIGNAL  BOOLEAN  M2  (  OUTl  DECODER-WITH-OUTPUT  AND-M2-B 
)  import-path:  (  DRIVE-DECODER  DECODER-WITH-OUTPUT 
)  import-ownar:  DECODER-WITH-OUTPUT 
INI  SIGNAL  BOOLEAN  Ml  (  OUTl  DECODER-WITH-OUTPUT  AND-Ml-B 
)  in5)ort-path:  (  DRIVE-DECODER  DECODER-WITH-OUTPUT 
)  import-ownar:  DECODER-WITH-OUTPUT 
INI  SIGNAL  BOOLEAN  MO  (  OUTl  DECODER-WITH-OUTPUT  AND-MO-B 
)  import-path:  <  DRIVE-DECODER  DECODER-WITH-OUTPUT 
)  inqport-owner:  DECODER-WITH-OUTPUT 
IN2  SIGNAL  BOOLEAN  AND-M7-B  (  OUTl  DRIVE-DECODER  SWITCH-NULL 
)  import-path:  (  DRIVE-DECODER  DECODER-WITH-OUTPUT 
)  import-ownar:  DECODER-WITH-OUTPUT 
INI  SIGNAL  BOOLEAN  AND-M7-B 

(  OUTl  DECODER-WITH-OUTPUT  AND-M7-A 
)  import-path:  (  DRIVE-DECODER  DECODER-WITH-OUTPUT 
)  inyort-ownar:  DECODER-WITH-OUTPUT 
IN2  SIGNAL  BOOLEAN  AND-M7-A  (  OUTl  ADDERS  LAST-OR 
)  import -path:  (  DRIVE-DECODER  DECODER-WITH-OUTPUT 
)  import-ownar:  DECODER-WITH-OUTPUT 
INI  SIGNAL  BOOLEAN  AND-M7-A  (  OUTl  HA2  HA2-N0T 

)  import-path:  (  DRIVE-DECODER  DECODER-WITH-OUTPUT 
)  import-ownar:  DECODER-WITH-OUTPUT 
IN2  SIGNAL  BOOLEAN  AND-M6-B  (  OUTl  DRIVE-DECODER  SWITCH-NULL 
)  import-path:  (  DRIVE-DECODER  DECODER-WITH-OUTPUT 
)  import-ownar:  DECODER-WITH-OUTPUT 
INI  SIGNAL  BOOLEAN  AND-H6-B 

(  OUTl  DECODER-WITH-OUTPUT  AND-M6-A 
)  import-path:  (  DRIVE-DECODER  DECODER-WITH-OUTPUT 
)  import-owner:  DECODER-WITH-OUTPUT 
IN2  SIGNAL  BOOLEAN  AND-M6-A  (  OUTl  ADDERS  LAST-OR 
)  import-path:  (  DRIVE-DECODER  DECODER-WITH-OUTPUT 
)  iiiq>ort -owner:  DECODER-WITH-OUTPUT 
INI  SIGNAL  BOOLEAN  AND-M6-A  (  OUTl  DECODER-WITH-OUTPUT  NOT-Z 
)  itq>ort-path:  (  DRIVE-DECODER  DECODER-WITH-OUTPUT 
)  import-owner:  DECODER-WITH-OUTPUT 
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IK2  SIGNAL  BOOLEAN  AND-N5-B  (  OUTl  DRIVE-DECODER  SWITCH-NULL 
)  iiq>ort-path:  (  DRIVE-DECODER  DECODER-HITH-ODTPUT 
)  import-ovnar :  DECODER-WITH-OUTPOT 
INI  SIGNAL  BOOLEAN  AND-MS-B 

(  OUTl  DECODER-HITH-OUTPUT  AND-M5-A 
)  in5)ort-path:  (  DRIVE-DECODER  DECODER-WITH-OUTPDT 
)  import-oimar:  DECODER-WITH-OUTPUT 
IN2  SIGNAL  BOOLEAN  AND-M5-A  (  OUTl  DECODER-WITH-OUTPUT  NOT-Y 
)  in^iort-patli:  (  DRIVE-DECODER  DECODER-WITH-OUTPUT 
)  import-ovner :  DECODER-WITH-OUTPUT 
INI  SIGNAL  BOOLEAN  AND-M6-A  (  OUTl  HA2  HA2-N0T 

)  import -path:  (  DRIVE-DECODER  DECODER-WITH-OUTPUT 
)  in^ort-ovnar:  DECODER-WITH-OUTPUT 
IN2  SIGNAL  BOOLEAN  AND-N4-B  (  OUTl  DRIVE-DECODER  SWITCH-NULL 
)  import-path:  (  DRIVE-DECODER  DECODER-WITH-OUTPUT 
)  import-ovnar:  DECODER-WITH-OUTPUT 
INI  SIGNAL  BOOLEAN  AND-M4-B 

(  OUTl  DECODER-WITH-OUTPUT  AND-M4-A 
)  import-path:  (  DRIVE-DECODER  DECODER-WITH-OUTPUT 
)  is^ort-OHnar:  DECODER-WITH-OUTPUT 
IN2  SIGNAL  BOOLEAN  AND-M4-A  (  OUTl  DECODER-HITH-OUTPUT  NOT-Y 
)  import-path:  (  DRIVE-DECODER  DECODER-HITH-ODTPUT 
)  iiiq)ort-ownor:  DECODER-HITH-OUTPUT 
INI  SIGNAL  BOOLEAN  AND-M4-A  (  OUTl  DECODER-HITH-OUTPUT  NOT-Z 
)  import-path:  <  DRIVE-DECODER  DECODER-HITH-OUTPUT 
)  import-ownar:  DECODER-WITH-OUTPUT 
IN2  SIGNAL  BOOLEAN  AND-M3-B  <  OUTl  DECODER-HITH-OUTPUT  NOT-X 
)  import-path:  (  DRIVE-DECODER  DECuDER-WITH-OUTPDT 
)  import-ovnar:  DECODER-HITH-OUTPUT 
INI  SIGNAL  BOOLEAN  AND-H3-B 

(  OUTl  DECODER-WITH-OUTPUT  AND-M3-A 
)  in5)ort-path:  <  DRIVE-DECODER  DECODER-HITH-ODTPUT 
)  import-ovnar:  DECODER-HITH-ODTPUT 
IN2  SIGNAL  BOOLEAN  AND-H3-A  (  OUTl  HA2  HA2-N0T 
)  import-path:  (  DRIVE-DECODER  DECODER-HITH-OUTPUT 
)  import-ovnar:  DECODER-HITH-OUTPUT 
INI  SIGNAL  BOOLEAN  AND-M3-A  (  OUTl  ADDERS  LAST-OR 
)  import-path:  (  DRIVE-DECODER  DECODER-HITH-ODTPUT 
)  inport-ovnar :  DECODER-HITH-ODTPUT 
IN2  SIGNAL  BOOLEAN  AND-M2-B  (  OUTl  DECODER-HITH-ODTPUT  NOT-X 
)  inport -path:  (  DRIVE-DECODER  DECODER-HITH-ODTPUT 
)  inport -ovnar:  DECODER-HITH-OUTPUT 
INI  SIGNAL  BOOLEAN  AND-M2-B 

(  OUTl  DECODER-WITH-OUTPUT  AND-M2-A 
)  inport-path:  (  DRIVE-DECODER  DECODER-HITH-ODTPUT 
)  inport-ovnar :  DECODER-HITH-OUTPUT 
IN2  SIGNAL  BOOLEAN  AND-M2-A  (  OUTl  ADDER3  LAST-OR 
)  inport-path:  (  DRIVE-DECODER  DECODER-HITH-ODTPUT 
)  inport-ovnar:  DECODER-WITH-OUTPDT 
INI  SIGNAL  BOOLEAN  AND-M2-A  <  OUTl  DECODER-HITH-ODTPUT  NOT-Z 
)  import -path:  (  DRIVE-DECODER  DECODER-HITH-ODTPUT 
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)  iiq)ort-onx«r :  DECODER-WITB-ODTPDT 
IN2  SIGNAL  BOOLEAN  AND-Hl-B  (  OUTl  OECODER-WITE-OOTPUT  NOT-X 
)  import -path:  <  DRIVE-DECODER  DECODER-WITH-ODTPDT 
)  in5>ort-owner :  DECODER-WITH-ODTPDT 
INI  SIGNAL  BOOLEAN  AND-Ml-B 

(  OUTl  DECODER-WITH-ODTPDT  AND-Ml-A 
)  inqjort-path:  (  DRIVE-DECODER  DECODER-WITH-ODTPDT 
)  in^ort-owner :  DECODER-WITH-ODTPDT 
IN2  SIGNAL  BOOLEAN  AND-Ml-A  (  OUTl  DECODER-WITH-ODTPDT  NOT-Y 
)  import -path:  (  DRIVE-DECODER  DECODER-WITH-ODTPDT 
)  io^ort-own«r :  DECODER-WITH-ODTPDT 
INI  SIGNAL  BOOLEAN  AND-Ml-A  (  ODTl  HA2  HA2-N0T 

)  iaqport-path:  (  DRIVE-DECODER  DECODER-WITH-ODTPDT 
)  import-ownor :  DECODER-WITH-ODTPDT 
IN2  SIGNAL  BOOLEAN  AND-MO-B  (  ODTl  DECODER-WITH-ODTPDT  NOT-X 
)  import-path:  (  DRIVE-DECODER  DECODER-WITH-ODTPDT 
)  import-ovner :  DECODER-WITH-ODTPDT 
INI  SIGNAL  BOOLEAN  AND-HO-B 

(  ODTl  DECODER-WITH-ODTPDT  AND-MO-A 
)  import-path:  (  DRIVE-DECODER  DECODER-WITH-OUTPUT 
)  import -owner :  DECODER-WITH-ODTPDT 
IN2  SIGNAL  BOOLEAN  AND-MO-A  (  ODTl  DECODER-WITH-ODTPDT  NOT-Y 
)  in5>ort-path:  (  DRIVE-DECODER  DECODER-WITH-ODTPDT 
)  import-ovner:  DECODER-WITH-ODTPDT 
INI  SIGNAL  BOOLEAN  AND-MO-A  (  ODTl  DECODER-WITH-ODTPDT  NOT-Z 
)  import-path:  (  DRIVE-DECODER  DECODER-WITH-ODTPDT 
)  import-owner:  DECODER-WITH-ODTPDT 
INI  SIGNAL  BOOLEAN  NOT-Z  (  ODTl  HA2  HA2-N0T 

)  import-path:  (  DRIVE-DECODER  DECODER-WITH-ODTPDT 
)  import-owner:  DECODER-WITH-ODTPDT 
INI  SIGNAL  BOOLEAN  NOT-Y  (  ODTl  ADDERS  LAST-OR 

)  import-path:  (  DRIVE-DECODER  DECODER-WITH-ODTPDT 
)  in5)ort -owner :  DECODER-WITH-ODTPDT 
INI  SIGNAL  BOOLEAN  NOT-X  (  OUTl  DRIVE-DECODER  SWITCH-NULL 
)  import-path:  (  DRIVE-DECODER  DECODER-WITH-ODTPDT 
)  import -owner :  DECODER-WITH-ODTPDT 

exports: 

OUTl  SIGNAL  BOOLEAN  AND-M7-B 

export-path:  (  DRIVE-DECODER  DECODER-WITH-ODTPDT 
)  export -owner:  DECODER-WITH-ODTPDT 
OUTl  SIGNAL  BOOLEAN  AND-M7-A 

export-path:  (  DRIVE-DECODER  DECODER-WITH-ODTPDT 
)  export-owner:  DECODER-WITH-ODTPDT 
OUTl  SIGNAL  BOOLEAN  AND-M6-B 

export-path:  (  DRIVE-DECODER  DECODER-WITH-ODTPDT 
)  export-owner:  DECODER-WITH-ODTPDT 
ODTl  SIGNAL  BOOLEAN  AND-N6-A 

export-path:  (  DRIVE-DECODER  DECODER-WITH-ODTPDT 
)  export -owner:  DECODER-WITH-ODTPDT 
ODTl  SIGNAL  BOOLEAN  AND-M5-B 

export-path:  (  DRIVE-DECODER  DECODER-WITH-ODTPDT 
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)  •xport-Qvner ;  DECODER-WITH-OOTPUT 
OUTl  SIGNAL  BOOLEAN  AND-M5-A 

•xport-path:  (  DRIVE-DECODER  DECODER-tfITH-OOTPUT 
)  export -osner:  DECODER-WITH-OUTPOT 
OUTl  SIGNAL  BOOLEAN  AND-N4-B 

export-path:  (  DRIVE-DECODER  DECODER-WITH-ODTPUT 
)  export -owner:  DECODER-WITH-ODTPUT 
OUTl  SIGNAL  BOOLEAN  AND-M4-A 

export-path:  (  DRIVE-DECODER  DECODER-WITH-ODTPUT 
)  export-owner:  DECODER-WITH-OUTPUT 
OUTl  SIGNAL  BOOLEAN  AND-N3-B 

export-path:  (  DRIVE-DECODER  DECODER-WITH-ODTPUT 
)  export -owner:  DECODER- WITH-OUTPUT 
I^'mTI  signal  boolean  AND-M3-A 

export-path:  (  DRIVE-DECODER  DECODER-WITH-OUTPOT 
)  export-owner:  DECODER-WITH-OOTPUT 
OUTl  SIGNAL  BOOLEAN  AND-M2-B 

export-path:  (  DRIVE-DECODER  DECODER-WITH-ODTPUT 
)  export-owner:  DECODER-WITH-OUTPOT 
OUTl  SIGNAL  BOOLEAN  AND-M2-A 

export-path:  (  DRIVE-DECODER  DECODER-WITH-OUTPOT 
)  export -owner:  DECODER-WITH-OOTPUT 
OUTl  SIGNAL  BOOLEAN  AND-Ml-B 

export-path:  <  DRIVE-DECODER  DECODER-WITH-ODTPUT 
)  export-owner:  DECODER-WITH-OUTPUT 
OUTl  SIGNAL  BOOLEAN  AND-Ni-A 

export-path:  (  DRIVE-DECODER  DECODER-WITH-ODTPUT 
)  export-owner:  DECODER-WITH-OUTPOT 
OUTl  SIGNAL  BOOLEAN  AND-MO-B 

export-path:  (  DRIVE-DECODER  DECODER-WITH-OUTPUT 
)  export-owner:  DECODER-WITH-OOTPUT 
OUTl  SIGNAL  BOOLEAN  AND-MO-A 

export-path:  (  DRIVE-DECODER  DECODER-WITH-ODTPUT 
)  export-owner:  DECODER-WITH-OUTPUT 
OUTl  SIGNAL  BOOLEAN  NOT-Z 

export-path:  (  DRIVE-DECODER  DECODER-WITH-OUTPOT 
)  export-owner:  DECODER-WITH-OUTPOT 
OUTl  SIGNAL  BOOLEAN  NOT-Y 

export-path:  <  DRIVE-DECODER  DECODER-WITH-ODTPUT 
)  export-owner:  DECODER-WITH-ODTPUT 
OUTl  SIGNAL  BOOLEAN  NOT-X 

export-path:  (  DRIVE-DECODER  DECODER-WITH-ODTPUT 
)  export-owner:  DECODER-WITH-ODTPUT 
OUTl  SIGNAL  BOOLEAN  SWITCH-NULL 

export-path:  (  DRIVE-DECODER  )  export-owner:  DRIVE-DECODER 
initialize  procedure:  update  procedure: 
update  SWITCH-NULL  update  DECODER-WITH-OUTPUT 
switch  SWITCH- 1 ADDEND  delay:  0  not  debounced 
manufacturer:  "  "  position:  ON  con^-x:  120  comp-y:  300 
switch  SWITCH-2A0DEND  delay:  0  not  debounced 
manufacturer:  "  "  position:  OFF  coo^-x:  116  con^-y:  402 
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switch  SUITCH-3ADDEND  dslay:  0  not  dsbouncsd 
manufacturer:  "  "  position:  OFF  coop-x:  120  cosqp-y:  100 
and-gate  Hil-ANDl  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  conp-x:  116  conp-y:  101 
and-gate  HA1-AND2  delay:  0  not  mil-spec  manufacturer:  "  ” 
power  level:  0.0  conp-x:  114  conp-y:  200 
or-gate  HAl-OR  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  conp-x:  240  comp-y:  154 
not-gate  HAl-NOT  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  conp-x:  351  conp-y:  158 
and-gate  HA2-AND1  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  conp-x:  113  conp-y:  93 
and-gate  HA2-AND2  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  conp-x:  108  conp-y:  197 
or-gate  HA2-0R  delay:  0  not  mil-spec  manufacturer:  “  " 
power  level:  0.0  conp-x:  233  cosp-y:  149 
not-gate  Hi2-N0T  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  conp-x:  369  conp-y:  151 
or-gate  LAST-OR  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  conp-x:  116  conp-y:  194 
not-gate  NOT-FIRSTX  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  conp-x:  251  conp-y:  295 
not-gate  NOT-FIRSTY  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  conp-x:  240  conp-y:  400 
not-gate  NOT-SECONDX  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  conp-x:  106  conp-y:  497 
not-gate  MOT-SECONDY  delay:  0  not  mil-spec  manufacturer:  *'  " 
power  level:  0.0  conp-x:  258  conp-y:  97 
led  SUN-OUTPUT  manufacturer:  "  "  color:  RED  conp-x:  249 
conp-y :  496 

led  CARRY-OUTPUT  manufacturer:  "  "  color:  RED  conp-x:  254 
conp-y :  190 

subsystem  ADDER3  is  controls: 

HAl,  HA2,  LAST-OR,  NOT-FIRSTX,  NOT-FIRSTY,  NOT-SECONDX, 
NOT-SECONDY,  SUM-OUTPUT,  CARRY-OUTPUT,  SWITCH- 1 ADDEND, 
SWITCH-2ADDEND,  SWITCH-3A0DEND 
inports: 

INI  SIGNAL  BOOLEAN  HAl-ANDl  (  OUTl  ADDERS  NOT-FIRSTX 
)  inport-path:  (  ADDERS  HAl  }  import-owner:  HAl 
IN2  SIGNAL  BOOLEAN  HAl-ANDl  (  OUTl  ADDERS  NOT-FIRSTY 
)  inport-path:  (  ADDERS  HAl  )  inport-owner:  HAl 
INI  SIGNAL  BOOLEAN  HA1-AND2  (  OUTl  ADDERS  SWITCH- 1 ADDEND 
)  inport-path:  (  ADDERS  HAl  )  inport-owner:  HAl 
IN2  SIGNAL  BOOLEAN  HA1-AND2  (  OUTl  ADDERS  SWITCH-2ADDEMD 
)  import-path:  (  ADDERS  HAl  )  inport-owner:  HAl 
INI  SIGNAL  BOOLEAN  HAl-OR  (  OUTl  HAl  HAl-ANDl 
)  inport -path:  (  ADDERS  HAl  )  inport-owner:  HAl 
IN2  SIGNAL  BOOLEAN  HAl-OR  (  OUTl  HAl  HA1-AND2 
)  inport-path:  (  ADDERS  HAl  )  inport-owner:  HAl 
INI  SIGNAL  BOOLEAN  HAl-NOT  (  OUTl  HAl  HAl-OR 
)  inport-path:  (  ADDERS  HAl  )  inport-owner:  HAl 
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INI  SIGNAL  BOOLEAN  HA2-AND1  (  OUTl  ADDERS  NOT-SECONDX 
)  u^ort-patb:  (  ADDERS  iA2  )  ioport-ovnar:  HA2 
IN2  SIGNAL  BOOLEAN  HA2-AMD1  (  OUT!  ADDERS  NOT-SECONDY 
)  ijq>ort-path:  (  ADDERS  HA2  )  ia^rt-ovnar:  HA2 
INI  SIGNAL  BOOLEAN  HA2-AND2  (  OUTl  EAl  HAl-NOT 
)  inport -path:  (  ADDERS  HA2  )  isport-ovnar:  HA2 
IN2  SIGNAL  BOOLEAN  BA2-AND2  (  OUTl  ADDERS  SUITCH-SADDEND 
)  inport -path:  (  ADDERS  HA2  )  inport-ownar:  HA2 
INI  SIGNAL  BOOLEAN  HA2-0R  (  OUTl  HA2  HA2-AND1 
)  inport-path:  (  ADDERS  HA2  )  inport-onxar:  HA2 
IN2  SIGNAL  BOOLEAN  BA2-0R  (  OUTl  HA2  HA2-AND2 
)  inport-path:  (  ADDERS  HA2  )  inport-ovnar:  HA2 
INI  SIGNAL  BOOLEAN  HA2-N0T  (  OUTl  BA2  EA2-0R 
}  inport-path:  (  ADDERS  HA2  )  inport-ownar:  HA2 
INI  SIGNAL  BOOLEAN  CARRY-OUTPUT  (  OUTl  ADDERS  LAST-OR 
)  inport-path:  (  ADDERS  )  inport-ovnar:  ADDERS 
INI  SIGNAL  BOOLEAN  SUM-OUTPUT  (  OUTl  HA2  HA2-N0T 
)  inport-path:  (  ADDERS  )  inport-ovnar:  ADDERS 
INI  SIGNAL  BOOLEAN  NOT-SECONDY  (  OUTl  ADDERS  SWITCH-SADDEND 
)  inport-path:  (  ADDERS  )  inport-ovnar:  ADDERS 
INI  SIGNAL  BOOLEAN  NOT-SECONDX  (  OUTl  HAl  HAl-NOT 
)  inport -path:  (  ADDERS  )  inport-ovnar:  ADDERS 
INI  SIGNAL  BOOLEAN  NOT-FIRSTY  (  OUTl  ADDERS  SWITCH-2ADDEND 
}  inport-path:  (  ADDERS  )  inport-ovnar:  ADDERS 
INI  SIGNAL  BOOLEAN  NOT-FIRSTX  (  OUTl  ADDERS  SWITCH- 1 ADDEND 
)  inport-path:  (  ADDERS  )  inport-ownar:  ADDERS 
IN2  SIGNAL  BOOLEAN  UST-OR  (  OUTl  HAl  HA1-AND2 
)  inport-path:  (  ADDERS  )  inport-ovnar:  ADDERS 
INI  SIGNAL  BOOLEAN  LAST-OR  (  OUTl  HA2  HA2-AND2 
)  inport-path:  (  ADDERS  )  inport-ovnar:  ADDERS 
exports: 

OUTl  SIGNAL  BOOLEAN  HAl-ANDl 

export -path:  (  ADDERS  HAl  }  axport-ovnar:  HAl 
OUTl  SIGNAL  BOOLEAN  HA1-AND2 

export -path:  (  ADDERS  HAl  )  axport-ovnar:  HAl 
OUTl  SIGNAL  BOOLEAN  HAl-OR 
export-path:  (  ADDERS  HAl  )  axport-ovnar:  HAl 
OUTl  SIGNAL  BOOLEAN  HAl-NOT 
export -path:  (  ADDERS  HAl  )  axport-ovnar:  HAl 
OUTl  SIGNAL  BOOLEAN  HA2-AND1 

export -path:  (  ADDERS  HA2  }  axport-ovnar:  BA2 
OUTl  SIGNAL  BOOLEAN  HA2-AND2 
export-path:  (  ADDERS  HA2  )  export-owner:  HA2 
OUTl  SIGNAL  BOOLEAN  HA2-0R 

export-path:  (  ADDERS  HA2  )  axport-ovnar:  HA2 
OUTl  SIGNAL  BOOLEAN  HA2-NOT 

export -path:  (  ADDERS  HA2  )  axport-ovnar:  HA2 
OUTl  SIGNAL  BOOLEAN  SWITCH-SADDEND 
export-path:  (  ADDERS  )  axport-ovnar:  ADDERS 
OUTl  SIGNAL  BOOLEAN  SHITCH-2ADDEND 

export -path:  (  ADDERS  )  export-owner:  ADDERS 
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OUTl  SIGNAL  BOOLEAN  SWITCH- 1AIN>END 

•zport-path:  (  ADDERS  }  axport-oniar :  ADDERS 
OUTl  SIGNAL  BOOLEAN  NOT-SECONDY 

•zport-path:  (  ADDERS  }  «zport-oim«r :  ADDERS 
OUTl  SIGNAL  BOOLEAN  NOT-SECONDX 

•zport-path:  (  ADDERS  )  •zport-ovaar :  ADDERS 
OUTl  SIGNAL  BOOLEAN  NOT-FIRSTY 

•zport-path:  (  ADDERS  )  azport-oimor :  ADDERS 
OUTl  SIGNAL  BOOLEAN  NOT-FIRSTX 

•zport-path:  (  ADDERS  )  azport-oimor:  ADDERS 
OUTl  SIGNAL  BOOLEAN  UST-OR 
•zport-path:  (  ADDERS  )  azport-oiiaor:  ADDERS 
initializo  procodura:  updata  procadura: 
updata  SWITCH- 1 ADDEND  updata  SWITCH-2ADDEND 
updata  SWITCH-SADDEND  updata  NOT-FIRSTX  updata  NOT-FIRSTY 
updata  HAl  updata  NOT-SECONDX  updata  NOT-SECONDY  updata  HA2 
updata  LAST-OR  updata  CARRY-OUTPUT  updata  SUM-OUTPUT 


and-gata  AND-MO-A  dalay:  0  not 
povar  laval:  0.0  coiq>-z:  S71 
and-gata  AND-MO-B  dalay:  0  not 
povar  laval:  0.0  coop-z:  916 
and-gata  AND-Nl-A  dalay:  0  not 
povar  laval:  0.0  con^-z:  569 
and-gata  AND-Hl-B  dalay:  0  not 
povar  laval:  0.0  comp-z:  927 
and-gata  AND-M2-A  dalay:  0  not 
povar  laval:  0.0  con^-z:  567 
and-gata  AND-M2-B  dalay:  0  not 
povar  laval:  0.0  comp-z:  9S3 
and-gata  AND-NS-A  dalay:  0  not 
povar  laval:  0.0  conq>-z:  567 
and-gata  AND-MS-B  dalay:  0  not 
povar  laval:  0.0  con^-z:  934 
and-gata  AND-N4-A  dalay:  0  not 
povar  laval:  0.0  coiq>-z:  767 
and-gata  AND-N4-B  dalay:  0  not 
povar  laval:  0.0  con^-z:  916 
and-gata  AND-M5-A  dalay:  0  not 
povar  laval:  0.0  con^-z:  753 
and-gata  AND-H5-B  dalay:  0  not 
povar  laval:  0.0  cottp-z:  921 
and-gata  AND-M6-A  dalay:  0  not 
povar  laval:  0.0  conp-z:  765 
and-gata  AND-M6-B  dalay:  0  not 
povar  laval:  0.0  coo^-z:  930 
and-gata  AND-H7-A  dalay:  0  not 
povar  laval:  0.0  conp-z:  767 
and-gata  AND-M7-B  dalay:  0  not 
povar  laval:  0.0  con^-z:  931 
lad  HO  manulacturar :  "  "  color 
lad  Ml  manufacturar :  "  "  color 


mil-apac  manufacturar:  "  " 
comp-y:  755 

mil-apac  manufacturar:  "  " 
coB^-y:  758 

mil-apac  manufacturar:  "  " 
coiq>-y:  636 

mil-apac  manufacturar:  "  " 
eoiq>-y:  647 

mil-apac  manufacturar:  "  " 
coiq>-y:  553 

mil-apac  manufacturar:  "  " 
comp-j:  548 

mil-apac  manufacturar:  "  " 
coiq>-y:  468 

mil-apac  manufacturar:  "  " 
con^-y:  467 

mil-apac  manufacturar:  "  " 
comp-y:  360 

mil-apac  manufacturar:  "  " 
conp-y:  367 

mil-apac  manufacturar:  "  " 
comp-y:  256 

mil-apac  manufacturar:  "  " 
conp-y:  267 

mil-apac  manufacturar:  "  " 
comp-y:  167 

mil-apac  manufacturar:  "  " 
conp-y:  163 

mil-apac  manufacturar:  "  " 
conp-y:  57 

mil-apac  manufacturar:  "  " 
conp-y:  47 

:  RED  comp-z:  1037  conp-y:  754 
:  RED  conp-z:  1035  conp-y:  660 
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led  N2  manufacturer:  "  "  color:  RED  cob^-z:  1035  coap-y:  549 

led  N3  manufacturer:  "  "  color:  RED  comp-z:  1035  coap-y:  463 

led  N4  manufacturer:  "  “  color:  RED  coap-z:  1036  coa^-y:  368 

led  H5  manufacturer:  "  “  color:  RED  con^-z:  1031  coap-y:  264 

led  N6  manufacturer:  “  "  color:  RED  coap-z:  1039  coap-y:  150 

led  M7  manufacturer:  "  "  color:  RED  coap-z:  1050  coap-y:  44 

not-gate  NOT-X  delay:  0  not  aiil-apec  manufacturer:  "  " 
power  level:  0.0  coap-z:  730  coap-y:  596 
not-gate  NOT-Y  delay:  0  not  adl-spec  manufacturer:  ”  " 
power  level:  0.0  coap-z:  225  coap-y:  354 
not-gate  NOT-Z  delay:  0  not  mil-spec  manufacturer:  "  “ 
power  level:  0.0  coap-z:  219  coap-y:  166 
subsystem  DECODER-WITH-ODTPUT  is  controls: 

NOT-X,  NOT-Y,  NOT-Z,  AND-MO-A,  AND-MO-B,  AND-Ml-A, 

AND'Ml-B,  AND-H2-A,  AND-M2-B,  AND-M3-A,  AND-H3-B,  AND-N4-A, 
AND-M4-B,  AND-M6-A,  AND-M5-B,  AND-M6-A,  AND-M6-B,  AND-M7-A, 
AND-M7-B,  MO,  Ml,  M2,  M3,  M4,  MS,  M6, 

M7  iaports:  ezports:  initialize  procedure: 
update  procedure: 

update  NOT-X  update  NOT-Y  update  NOT-Z  update  AND-MO-A 
update  AND-MO-B  update  AND-Ml-A  update  AND-Ml-B 
update  AN0-M2-A  update  AND-M2-B  update  AND-M3-A 
update  AND-M3-B  update  AMD-M4-A  update  AND-M4-B 
update  AN0-M5-A  update  AND-N5-B  update  AND-M6-A 
update  AND-M6-B  update  AND-M7-A  update  AND-H7-B  update  MO 
update  Ml  update  M2  update  M3  update  M4  update  MS  update  M6 
update  M7 

subsystem  HAl  is  controls: 

HAl-ANDl,  HA1-AND2,  HAl-OR,  HAl-NOT  imports:  ezports: 
initialize  procedtire:  update  procedure: 

update  HAl-ANDl  update  HA1-AND2  update  HAl-OR  update  HAl-NOT 
comp-z:  460  comp-y:  297 
subsystem  HA2  is  controls: 

HA2-AND1,  HA2-AND2,  HA2-0R,  HA2-N0T  iaports:  ezports: 
initialize  procedure:  update  procedure: 

update  HA2-AND1  update  HA2-AND2  update  HA2-0R  update  HA2-N0T 
conq>-z:  468  coa^-y:  88 


C.6  BCD-ADDER  Application 

This  application  tests  a  subsystem  implementation  of  a  BCD-adder  using  primitive  gates  and 
half-adders. 


application  definition  BCD-ADDER 
ezecution-mode :  NON-EVENT-DRIVEN-SEqUENTIAL 
application  BCD-ADDER  is  controls:  DRIVE-BCD-ADDER 
update  procedure:  update  DRIVE-BCD-ADDER 
subsystem  DRIVE-BCD-ADDER  is  controls: 

BCD-ADD,  ADDENDl,  ADDEND2,  ADDEND3,  ADDEND4,  CARRY-IN, 
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HDU.  AOGEMOl.  1U6E3ID2.  iUGElDS.  UJCXmA.  CABKY-OUT.  S8. 

S4.  S2.  SI 
inports: 

IN2  SIGNAL  BOOLEAN  BCD-ORA  (  OUTl  FOUB-BIT-l  CABRY-4~1 

}  ioport-path:  (  DRIVE-BCD- ADDER  BCD- ADD  )  iaport-o«n«r ; 

BCD-ADD 

INI  SIGNAL  BOOLEAN  BCD-ORA  (  QUTl  BCD-A]»>  BCD-ANDl 

)  inport-path:  (  DRIVE-BCD- ADDER  BCD-ADD  )  ioport-oimar : 
BCD-ADD 

IN2  SIGNAL  BOOLEAN  BCD-OR  (  OUTl  BCD-ADD  BCD-AND2 

)  i]q)ort-path:  (  DRIVE-BCD-ADDER  BCD-AIN)  )  ioport -owner : 
BCD-ADD 

INI  SIGNAL  BOOLEAN  BCD-OR  (  OUTl  BCD-ADD  BCD-ORA 
)  import-path:  (  DRIVE-BCD-ADDER  BCD-ADD  )  import-owner: 
BCD-ADD 

IN2  SIGNAL  BOOLEAN  BCD-AND2  (  S  FOUR-BIT-1  HA2B-1 

)  import -path:  (  DRIVE-BCD-ADDER  BCD-ADD  )  import -owner: 
BCD-ADD 

INI  SIGNAL  BOOLEAN  BCD-AND2  (  S  FOtm-BIT-1  HA4B-1 

)  import -path:  (  DRIVE-BCD-ADDER  BCD-ADD  )  import-owner: 
BCD-ADD 

IN2  SIGNAL  BOOLEAN  BCD-ANDl  (  S  FOUR-BIT-1  HA3B-1 

)  inport-path:  (  DRIVE-BCD-ADDER  BCD-ADD  )  import-owner: 
BCD-ADD 

INI  SIGNAL  BOOLEAN  BCD-ANDl  (  S  FOUR-BIT-1  HA4B-1 

)  import-path:  <  DRIVE-BCD-ADDER  BCD-ADD  >  import-owner: 
BCD-ADD 

INI  SIGNAL  BOOLEAN  BAlA-1  (  OUTl  DRIVE-BCD-ADDER  CARRY-IN 
)  import-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FOUR-BIT- 1 
)  import -owner:  FOUR-BIT- 1 

IN2  SIGNAL  BOOLEAN  HAlA-1  (  OUTl  DRIVE-BCD-ADDER  ADDENDl 
)  import-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-1 
)  import-owner:  FOUR-BIT-1 

INI  SIGNAL  BOOLEAN  HAlB-1  (  S  FOUR-BIT-1  HAlA-1 

)  import-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FOOR-BIT-1 
)  import-owner:  FOUR-BIT-1 

IN2  SIGNAL  BOOLEAN  BAlB-1  (  OUTl  DRIVE-BCD-ADDER  AUGENDl 
)  import-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-1 
)  import-owner:  FODR-BIT-1 

INI  SIGNAL  BOOLEAN  HA2A-1  (  OUTl  FOUR-BIT-l  CARRY-1-1 
)  import-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-1 
)  import-owner:  FODR-BIT-1 

IN2  SIGNAL  BOOLEAN  HA2A'l  (  OUTl  DRIVE-BCD-ADDER  ADDEND2 
)  import-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-1 
)  import-owner:  FODR-BIT-1 

INI  SIGNAL  BOOLEAN  EA2B-1  (  S  FOUR-BIT-1  HA2A-1 

)  import-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-1 
)  import -owner:  FOUR-BIT- 1 

IN2  SIGNAL  BOOLEAN  HA2B-1  (  OUTl  DRIVE-BCD-ADDER  AUGEND2 
)  import-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FOUR-BIT-1 
)  import-owner:  FODR-BIT-1 
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INI  SIGNAL  BOOLEAN  HA3A-1  (  OUTl  FODR-BIT-1  CABRY-2-1 
)  insert -path:  (  DRIVE-BCD- ADDER  BCD- ADD  FODR-BIT-1 
)  i]q>ort-o«i6r:  FODR-BIT-1 

IN2  SIGNAL  BOOLEAN  HA3A-1  (  ODTl  DRIVE-BCD-ADDER  ADDENDS 
)  i]q>ort-path:  (  DRIVE-BCD-ADDER  BCD-MDD  FODR-BIT-1 
)  iiq>ort-omer :  FODR-BIT-1 
INI  SIGNAL  BOOLEAN  HA3B-1  (  S  FODR-BIT-1  HA3A-1 

)  insert-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-1 
)  insort-ovnar:  FODR-BIT-1 

IN2  SIGNAL  BOOLEAN  HA3B-1  (  ODTl  DRIVE-BCD-ADDER  ADGEND3 
)  insort-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-1 
)  insort -ovnar:  FODR-BIT-1 

INI  SIGNAL  BOOLEAN  HA4A-1  (  ODTl  FODR-BIT-1  CARRY-3-1 
)  insort-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-1 
)  insort-oimar :  FODR-BIT-1 

IN2  SIGNAL  BOOLEAN  BA4A-1  (  ODTl  DRIVE-BCD-ADDER  ADDENDA 
)  insort-path:  <  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-1 
)  insort-oimar:  FODR-BIT-1 
INI  SIGNAL  BOOLEAN  HA4B-1  (  S  FODR-BIT-1  HA4A-1 

)  insort-path:  <  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-1 
)  insort-oimar:  FODR-BIT-1 

IN2  SIGNAL  BOOLEAN  HA4B-1  (  ODTl  DRIVE-BCD-ADDER  ADGEND4 
)  insort-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-1 
)  insort -ovnar:  FODR-BIT-1 
INI  SIGNAL  BOOLEAN  CARRY-1-1  (  C  FODR-BIT-1  HAlA-1 
)  insort-path:  <  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-1 
)  insort-oimar:  FODR-BIT-1 
IN2  SIGNAL  BOOLEAN  CARRY-1-1  (  C  FODR-BIT-1  HAlB-1 
)  insort-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-1 
)  insort-ovnar :  FODR-BIT-1 
INI  SIGNAL  BOOLEAN  CARRY-2-1  (  C  FODR-BIT-1  HA2A-1 
)  insort-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-1 
)  insort-ovnar:  FODR-BIT-1 
IN2  SIGNAL  BOOLEAN  CARRY-2-1  (  C  FODR-BIT-1  HA2B-1 
)  insort-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-l 
)  insort-ovnar:  FODR-BIT-1 
INI  SIGNAL  BOOLEAN  CARRY-3-1  (  C  FODR-BIT-1  HA3B-1 
)  insort-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-1 
)  insort-ovnar:  FODR-BIT-1 
IN2  SIGNAL  BOOLEAN  CARRY-3-1  (  C  FODR-BIT-1  HA3A-1 
)  insort-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-1 
)  insort-ovnar:  FODR-BIT-1 
INI  SIGNAL  BOOLEAN  CARRY-4-1  (  C  FODR-BIT-1  HA4B-1 
)  insort-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-1 
)  insort-ovnar:  FODR-BIT-1 
IN2  SIGNAL  BOOLEAN  CARRY-4-1  (  C  FODR-BIT-1  HA4A-1 
)  import-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-1 
)  import-ovnar :  FODR-BIT-1 

INI  SIGNAL  BOOLEAN  HAlA-2  (  ODTl  DRIVE-BCD-ADDER  NDLL 
)  import-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-2 
)  insort-ovnar:  FODR-BIT-2 
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IN2  SIGNAL  BOOLEAN  HAlA-2  (  S  FOOB-BIT-1  HAlB-1 
)  ioport-path:  (  DR1VE-BC3>-A1»E&  BCD-AOD  FOlJR-BIT-2 
)  inport-owacr :  FOUE-BIT-2 
INI  SIGNAL  BOOLEAN  HAlB-2  (  S  FOUR-BIT-2  IAlA-2 
)  inport-patR:  (  DRIVE-BCD- ADDER  BCD- AM)  FOUR-BIT-2 
)  iiq>ort-oim«r :  FOUR-BIT-2 

IN2  SIGNAL  BOOLEAN  HAlB-2  (  OUTl  DRIVE-BCD-AIN}ER  NULL 
}  import-path:  (  DRIVE-BCD-ADDER  BCS-ADD  FOUR-BIT-2 
)  import -oimar:  FOUR-BIT-2 

INI  SIGNAL  BOOLEAN  HA2A-2  (  OUTl  FOUR-BIT-2  CARRY-1-2 
)  ioport-path:  (  DRIVE-BCD-ADDER  BCD- AIN)  FOUR-BIT-2 
)  import-om«r:  FOUR-BIT-2 
IN2  SIGNAL  BOOLEAN  HA2A-2  (  S  FOUR-BIT-1  HA2B-1 

)  ioport-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FOUR-BIT-2 
)  ioport-oimor :  FOUR-BIT-2 
INI  SIGNAL  BOOLEAN  HA2B-2  (  S  FOUR-BIT-2  HA2A-2 
)  ioport-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FOUR-BIT-2 
)  ioport-omer:  FOUR-BIT-2 
IN2  SIGNAL  BOOLEAN  HA2B-2  (  OUTl  BCD-AOD  BCD-OR 
)  import-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FOUR-BIT-2 
)  import -ornnor:  FOUR-BIT-2 

INI  SIGNAL  BOOLEAN  HA3A-2  (  OUTl  FOUR-BIT-2  CARRY-2-2 
)  ioport-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-2 
)  ioport -owner:  FOUR-BIT-2 
IN2  SIGNAL  BOOLEAN  EA3A-2  (  S  FOUR-BIT-1  HA3B-1 

)  ioport-path:  (  DRIVE-BCD-ADDER  Ka>-ADD  FOUR-BIT-2 
)  ioport-owner :  FOUR-BIT-2 
INI  SIGNAL  BOOLEAN  BA3B-2  (  S  FOUR-BIT-2  HA3A-2 
)  ioport-path:  <  DRIVE-BCD-ADDER  BCD-ADD  FOUR-BIT-2 
)  ioport-owner :  FOUR-BIT-2 
IN2  SIGNAL  BOOLEAN  HA3B-2  (  OUTl  BCD-AOD  BCD-OR 

)  ioport-path:  (  DRIVE-BCD-ADDER  BCD-AOD  FODR-BIT-2 
)  ioport-ovner :  FOUR-BIT-2 

INI  SIGNAL  BOOLEAN  HA4A-2  (  OUTl  FOUR-BIT-2  CARRY-3-2 
)  ioport-path:  <  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-2 
)  ioport-owner :  FOUR-BIT-2 
IN2  SIGNAL  BOOLEAN  HA4A-2  (  S  FOUR-BIT-1  HA4B-1 

)  import-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-2 
)  ioport-ovner:  FODR-BIT-2 
INI  SIGNAL  BOOLEAN  HA4B-2  (  S  FOUR-BIT-2  HA4A-2 
)  import-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-2 
)  ioport-ovner:  FODR-BIT-2 

IN2  SIGNAL  BOOLEAN  HA4B-2  (  OUTl  DRIVE-BCD-ADDER  NULL 
)  ioport-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-2 
)  ioport-ovner:  FOUR-BIT-2 
INI  SIGNAL  BOOLEAN  CARRY-1-2  (  C  FOUR-BIT-2  EAlA-2 
)  import -path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-2 
)  import-ovner:  FODR-BIT-2 
IN2  SIGNAL  BOOLEAN  CARRY-1-2  (  C  FODR-BIT-2  HAlB-2 
)  ioport-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-2 
)  ioport-ovner:  FOUR-BIT-2 
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INI  SIGNAL  BOOLEAN  CAIlRY-2-2  (  C  FOUR-BIT-2  HA2A-2 
)  iiq>ort-patti:  (  DRIVE-BCD-ADDER  BCD- ADD  FOUR-BIT-2 
)  i]Bport-oiin«r :  FOUR-BIT-2 
IN2  SIGNAL  BOOLEAN  CARRY-2-2  (  C  FOUR-BIT-2  HA2B-2 
)  uqport-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FOUR-BIT-2 
)  import-ovnar :  FOUR-BIT-2 
INI  SIGNAL  BOOLEAN  CARRY-3-2  (  C  FOUR-BIT-2  HA3B-2 
)  iiq)ort-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-2 
)  Inport-oimaz :  FODR-BIT-2 
IN2  SIGNAL  BOOLEAN  CARRY-3-2  (  C  FODR-BIT-2  HA3A-2 
)  ia9)ort-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-2 
)  iiaport-ownar :  FODR-BIT-2 
INI  SIGNAL  BOOLEAN  CARRY-4-2  (  C  FOUR-BIT-2  HA4B-2 
}  import-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FOUR-BIT-2 
)  iiq>ort-ownar :  FOUR-BIT-2 
IN2  SIGNAL  BOOLEAN  CARRY-4-2  (  C  FOUR-BIT-2  HA4A-2 
)  import -path:  (  DRIVE-BCD-ADDER  BCD-ADD  FOUR-BIT-2 
)  import-owner:  FOUR-BIT-2 
INI  SIGNAL  BOOLEAN  SI  (  S  FOUR-BIT-2  HAlB-2 

)  import-path:  (  DRIVE-BCD-ADDER  )  ioport-ovner : 
DRIVE-BCD-ADDER 

INI  SIGNAL  BOOLEAN  S2  (  S  FOUR-BIT-2  HA2B-2 

)  import-path:  (  DRIVE-BCD-ADDER  )  io^ort-ovner : 
DRIVE-BCD-ADDER 

INI  SIGNAL  BOOLEAN  S4  (  S  FOUR-BIT-2  HA3B-2 
)  import -path:  (  DRIVE-BCD-ADDER  )  ioport-owner : 
DRIVE-BCD-ADDER 

INI  SIGNAL  BOOLEAN  SB  (  S  FOUR-BIT-2  HA4B-2 

)  import-path:  (  DRIVE-BCD-ADDER  )  uq>ort-owner : 
DRIVE-BCD-ADDER 

INI  SIGNAL  BOOLEAN  CARRY-OUT  (  OUTl  BCD-ADD  BCD-OR 
)  iiiq)ort-path:  (  DRIVE-BCD-ADDER  )  import-owner: 
DRIVE-BCD-ADDER 

exports : 

OUTl  SIGNAL  BOOLEAN  BCD-ORA 

export-path:  (  DRIVE-BCD-ADDER  BCD-ADD  }  export-owner: 
BCD-ADD 

OUTl  SIGNAL  BOOLEAN  BCD-OR 

export-path:  (  DRIVE-BCD-ADDER  BCD-ADD  )  export-owner 
BCD-ADD 

OUTl  SIGNAL  BOOLEAN  BCD-AND2 

export-path:  (  DRIVE-BCD-ADDER  BCD-ADD  )  export-owner 
BCD-ADD 

OUTl  SIGNAL  BOOLEAN  BCD-ANDl 

export-path:  (  DRIVE-BCD-ADDER  BCD-ADD  )  export-owner 
BCD-ADD 

S  SIGNAL  BOOLEAN  HAlA-1 

export-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FOUR-BIT-1 
)  export-owner:  FOUR-BIT- 1 
C  SIGNAL  BOOLEAN  HAlA-1 

export-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FOUR-BIT- 1 
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)  cxport-omar:  FOUR-BIT- i 
S  SIGNAL  BOOLEAN  HAlB-1 

export-path:  (  DRIVE-BCD-ADOER  BCD-AOD  FOUR-BIT- 1 
)  export -o«ier:  FOUR-BIT- 1 
C  SIGNAL  BOOLEAN  HAlB-1 

export-path:  (  DRIVE-BCD- ADDER  BCD- ADD  FOUR-BIT- 1 
)  export-owner:  FOUR-BIT-1 
S  SIGNAL  BOOLEAN  HA2A-1 

export-path:  (  DRIVE-BCD-ADDER  BCT-ADD  FOOR-BIT-1 
)  export-owner:  FOUR-BIT-1 
C  SIGNAL  BOOLEAN  HA2A-1 

export-path:  (  DRIVE-BCD-ADDER  BCD-AOD  FOUR-BIT- 1 
)  export-owner:  FOUR-BIT-1 
S  SIGNAL  BOOLEAN  HA2B-1 

export-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FOOR-BIT-1 
)  export-owner:  FOOR-BIT-1 
C  SIGNAL  BOOLEAN  HA2B-1 

export-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FOUR-BIT- 1 
)  export-owner:  FOOR-BIT-1 
S  SIGNAL  BOOLEAN  HA3A-1 

export-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-1 
)  export-owner:  FODR-BIT-1 
C  SIGNAL  BOOLEAN  HA3A-1 

export-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FOUR-BIT- 1 
)  export-owner:  FOOR-BIT-1 
S  SIGNAL  BOOLEAN  HA3B-1 

export-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FOOR-BIT-1 
)  export-owner:  FOUR-BIT-1 
C  SIGNAL  BOOLEAN  HA3B-1 

export-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-1 
)  export -owner :  FOUR-BIT- 1 
S  SIGNAL  BOOLEAN  HA4A-1 

export-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FOUR-BIT- 1 
)  export-owner:  FOOR-BIT-1 
C  SIGNAL  BOOLEAN  HA4A-1 

export-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FOUR-BIT- 1 
)  export-owner:  FODR-BIT-1 
S  SIGNAL  BOOLEAN  HA4B-1 

export -path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-1 
)  export-owner:  FOOR-BIT-1 
C  SIGNAL  BOOLEAN  HA4B-1 

export-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FOUR-BIT-1 
)  export-owner:  FOUR-BIT-1 
OUTl  SIGNAL  BOOLEAN  CARRY-1-1 

export-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-1 
)  export-owner:  FODR-BIT-1 
OUTl  SIGNAL  BOOLEAN  CARRY-2- 1 

export-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-1 
)  export-owner:  FOUR-BIT-1 
OUTl  SIGNAL  BOOLEAN  CARRY-3-1 

export-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-1 
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)  export -owner :  FOUR-BIT- 1 
OUTl  SIGNAL  BOOLEAN  CARRY-4-1 

export-path:  (  DRIVE-BCD-ADDER  BCD- ADD  FOUR-BIT- 1 
)  export -owner:  FOUR-BIT- 1 
S  SIGNAL  BOOLEAN  HAlA-2 

export-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FOUR-BIT-2 
)  export-owner:  FOUR-BIT-2 
C  SIGNAL  BOOLEAN  HAlA-2 

export-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FOUR-BIT-2 
)  export-owner:  FOUR-BIT-2 
S  SIGNAL  BOOLEAN  HAlB-2 

export-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FOUR-BIT-2 
)  export-owner:  FOUR-BIT-2 
C  SIGNAL  BOOLEAN  HAlB-2 

export-path:  <  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-2 
)  export-owner:  FOOR-BIT-2 
S  SIGNAL  BOOLEAN  HA2A-2 

export-path:  (  DRIVE-  CD-ADDER  BCD-ADD  FODR-BIT-2 
)  export -owner:  FOUR-BIT-2 
C  SIGNAL  BOOLEAN  HA2A-2 

export-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-2 
)  export -owner :  FOUR-BIT-2 
S  SIGNAL  BOOLEAN  HA2B-2 

export-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-2 
)  export-owner:  FOUR-BIT-2 
C  SIGNAL  BOOLEAN  HA2B-2 

export-path:  <  DRIVE-BCD-ADDER  BCD-ADD  FOUR-BIT-2 
)  export-owner:  FOUR-BIT-2 
S  SIGNAL  BOOLEAN  HA3A-2 

export-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODB-BIT-2 
)  export-owner:  FODR-BIT-2 
C  SIGNAL  BOOLEAN  HA3A-2 

export-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-2 
)  export-owner:  FODR-BIT-2 
S  SIGNAL  BOOLEAN  HA3B-2 

export-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-2 
)  export-owner:  FODR-BIT-2 
C  SIGNAL  BOOLEAN  HA3B-2 

export-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-2 
)  export-owner:  FODR-BIT-2 
S  SIGNAL  BOOLEAN  HA4A-2 

export-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FOUR-BIT-2 
)  export-owner:  FOUR-BIT-2 
C  SIGNAL  BOOLEAN  HA4A-2 

export-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-2 
)  export-owner:  FOUR-BIT-2 
S  SIGNAL  BOOLEAN  HA4B-2 

export-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FODR-BIT-2 
)  export-owner:  FOUR-BIT-2 
C  SIGNAL  BOOLEAN  HA4B-2 

export -path:  (  DRIVE-BCD-ADDER  BCD-ADD  FOUR-BIT-2 
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)  •xport-ovner :  FOUR-BIT-2 
OUTl  SIGNAL  BOOLEAN  CARRY- 1-2 

export-path:  (  DRIVE-BCD-ADDER  BCD- ADD  FOUR-BIT-2 
)  export-owner:  FOUR-BIT-2 
OUTl  SIGNAL  BOOLEAN  CARRY-2-2 

export -path:  (  DRIVE-BCD-ADDER  BCD-ADD  FOUR-BIT-2 
)  export-owner:  FOUB-BIT-2 
OUTl  SIGNAL  BOOLEAN  CARBY-3-2 

export-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FOUR-BIT-2 
)  export -owner :  FOUR-BIT-2 
OUTl  SIGNAL  BOOLEAN  CARRY-4-2 

export-path:  (  DRIVE-BCD-ADDER  BCD-ADD  FOUR-BIT-2 
)  export-owner:  FOUR-BIT-2 
OUTl  SIGNAL  BOOLEAN  NULL 

export -path:  (  DRIVE-BCD-ADDER  )  export-owner: 
DRIVE-BCD-ADDER 
OUTl  SIGNAL  BOOLEAN  AUGEND4 

export -path:  (  DRIVE-BCD-ADDER  )  export-owner: 
DRIVE-BCD-ADDER 
OUTl  SIGNAL  boolean  AUGEND3 

export-path:  (  DRIVE-BCD-ADDER  )  export-owner: 
DRIVE-BCD-ADDER 
OUTl  SIGNAL  BOOLEAN  AUGEND2 

export-path:  (  DRIVE-BCD-ADDER  )  export-owner: 
DRIVE-BCD-ADDER 
OUTl  SIGNAL  BOOLEAN  AUGENDl 

export-path:  (  DRIVE-BCD-ADDER  )  export-owner: 
DRIVE-BCD-ADDER 
OUTl  SIGNAL  BOOLEAN  CARRY-IN 

export -path:  (  DRIVE-BCD-ADDER  )  export -owner : 
DRIVE-BCD-ADDER 
OUTl  SIGNAL  BOOLEAN  ADDEND4 

export-path:  (  DRIVE-BCD-ADDER  )  export-owner: 
DRIVE-BCD-ADDER 
OUTl  SIGNAL  BOOLEAN  ADDENDS 

export-path:  (  DRIVE-BCD-ADDER  )  export-owner: 
DRIVE-BCD-ADDER 
OUTl  SIGNAL  BOOLEAN  ADOEND2 

export-path:  (  DRIVE-BCD-ADDER  )  export-owner: 
DRIVE-BCD-ADDER 
OUTl  SIGNAL  BOOLEAN  ADDENDl 

export-path:  (  DRIVE-BCD-ADDER  )  export-owner: 
DRIVE-BCD-ADDER 

initialize  procedure;  update  procedure: 
update  NULL  update  CARRY-IN  update  ADDENDl  update  ADDEND2 
update  ADDENDS  update  ADDEND4  update  AUGENDl  update  AUGEND2 
update  AUGENDS  update  AUGEND4  update  BCD-ADD 
update  CARRY-OUT  update  S8  update  S4  update  S2  update  SI 
subsystem  BCD-ADD  is  controls: 

FOUR-BIT-1,  FOUR-BIT-2.  BCD-ANDl,  BCD-AND2,  BCD-OR,  BCD-ORA 
imports:  exports:  initialize  procedure:  update  procedure: 
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updata  FOUR-BIT-1  update  BCD-ANDl  update  BCD-AND2 
update  BCD-QRR  update  BCD-QR  update  FOUR-BIT-2 
coiq>-x:  183  conq>-y:  495 
subsystem  FOUR-BIT-1  is  controls: 

HAlA-1,  HAlB-1,  HA2A-1,  HA2B-1,  HA3A-1,  HA3B-1.  HA4A-1. 
HA4B-1,  CARRY-1-1,  CARRY-2-1.  CARRY-3-1,  CARRY-4-1 
i]q>orts:  exports:  initialize  procedure:  update  procedure: 
update  HAlA-1  update  HAlB-1  update  CARRY-1-1  update  HA2A-1 
update  HA2B-1  update  CARRY-2-1  update  HA3A-1  update  HA3B-1 
update  CARRY-3-1  update  HA4A-1  update  HA4B-1 
update  CARRY-4- 1 
comp-x:  469  con5)-y:  347 
subsystem  FOUR-BIT-2  is  controls: 

HAlA-2.  HAlB-2.  HA2A-2.  HA2B-2.  HA3A-2,  HA3B-2.  HA4A-2. 
HA4B-2,  CARBY-1-2,  CARRY-2-2,  CARRY-3-2,  CARRY-4-2 
is^orts:  exports:  initialize  procedure:  update  proced\ire: 
update  HAlA-2  update  HAlB-2  update  CARRY-1-2  update  HA2A-2 
update  HA2B-2  update  CARRY- 2-2  update  HA3A-2  update  HA3B-2 
update  CARRY-3-2  update  HA4A-2  update  HA4B-2 
update  CARRY-4-2 
con5)-x:  167  comp-y:  348 

half-adder  HAlA-1  delay:  0  not  mil-spec  manufacturer:  "  " 
pover  level:  0.0  comp-x:  95  coiq>-y:  549 
half-adder  HAlB-1  delay:  0  not  mil-spec  manufacturer:  "  " 
pover  level:  0.0  comp-x:  260  conq>-y:  490 
or-gate  CARRY- 1-1  delay:  0  not  mil-spec  manufacturer:  "  " 
pover  level:  0.0  comp-x:  397  con^j-y:  551 
half-adder  HA2A-1  delay:  0  not  mil-spec  manufacturer:  "  " 
pover  level:  0.0  comp-x:  504  comp-y:  426 
half-adder  HA2B-1  delay:  0  not  mil-spec  manufacturer:  "  " 
pover  level:  0.0  comp-x:  604  comp-y:  549 
or-gate  CARRY-2-1  delay:  0  not  mil-spec  manufacturer:  "  " 
pover  level:  0.0  comp-x:  750  comp-y:  503 
half -adder  HA3A-1  delay:  0  not  mil-spec  manufacturer:  "  " 
pover  level:  0.0  con^-x:  789  comp-y:  342 
hedf-adder  HA3B-1  delay:  0  not  mil-spec  manufacturer:  "  ” 
pover  level:  0.0  comp-x:  240  coiq>-y:  300 
or-gate  CARRY- 3-1  delay:  0  not  mil-spec  manufacturer:  "  " 
pover  level:  0.0  comp-x:  120  con5>-y:  200 
half -adder  HA4A-1  delay:  0  not  mil-spec  manufacturer:  "  " 
pover  level:  0.0  comp-x:  240  comp-y:  200 
half-adder  HA4B-1  delay:  0  not  mil-spec  manufacturer:  "  " 
pover  level:  0.0  comp-x:  240  comp-y:  100 
or-gate  CARRY-4-1  delay:  0  not  mil-spec  manufacturer:  "  " 
pover  level:  0.0  comp-x:  120  comp-y:  100 
heQ.f -adder  HAlA-2  delay:  0  not  mil-spec  m2aiufacturer:  "  " 
pover  level:  0.0  conq)-x:  360  comp-y:  400 
half-adder  HAlB-2  delay:  0  not  mil-spec  manuf actxirer :  "  " 
pover  level:  0.0  comp-x:  360  con^-y:  300 
or-gate  CARRY-1-2  delay:  0  not  mil-spec  manufacturer:  "  " 
pover  level:  0.0  comp-x:  120  comp-y:  400 
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half-add«r  Hi2A-2  delay:  0  not  mil-apec  manufacturer: 

pover  level:  0.0  coiiq>-z:  360  coiq)-y:  200 
half -adder  HA2B-2  delay:  0  not  mil-apec  manufacturer:  "  " 
pover  level:  0.0  coiiq>-z:  360  comp-y:  100 
or-gate  CARRY-2-2  delay:  0  not  mil-apec  manufacturer:  "  " 
pover  level:  0.0  con^-z:  120  con^-y:  300 
half -adder  HA3A-2  delay:  0  not  mil-apec  manufacturer:  "  " 
pover  level:  0.0  conp-z:  240  comp-y:  400 
half-adder  HA3B-2  delay:  0  not  mil-apec  manufacturer:  "  " 
pover  level:  0.0  coiq>-z:  240  comp-y:  300 
or-gate  CARRY-3-2  delay:  0  not  mil-apec  manufacturer:  "  " 
pover  level:  0.0  coo^-z:  120  comp-y:  200 
hidf-adder  HA4A-2  delay:  0  not  mil-apec  manufacturer:  "  " 
pover  level:  0.0  con^-z:  240  conp-y:  200 
half -adder  HA4B-2  delay:  0  not  mil-apec  manufacturer:  "  " 
pover  level:  0.0  comp-z:  240  comp-y:  100 
or-gate  CARRY-4-2  delay:  0  not  mil-apec  manufacturer:  "  " 
pover  level:  0.0  comp-z:  120  comp-y:  100 
and-gate  BCO-ANDl  delay:  0  not  mil-apec  manufacturer:  "  " 
pover  level:  0.0  conp-z:  103  conp-y:  245 
and-gate  BCD-AND2  delay:  0  not  mil-spec  manufacturer:  "  " 
pover  level:  0.0  comp-z:  116  comp-y:  149 
or-gate  BCD-ORA  delay:  0  not  mil-spec  manufacturer:  "  " 
pover  level:  0.0  comp-z:  233  comp-y:  250 
or-gate  BCD-OR  delay:  0  not  mil-spec  manufacturer:  "  " 
pover  level:  0.0  conp-z:  376  comp-y:  212 
svitch  NULL  delay:  0  not  debounced  manufacturer:  "  " 
position:  OFF  conp-z:  360  conp-y:  200 
svitch  CARRY-IN  delay:  0  not  debounced  manufacturer:  "  " 
position:  OFF  comp-z:  360  conp-y:  300 
svitch  AODENDl  delay:  0  not  debounced  manufacturer:  "  " 
position:  ON  comp-z:  480  conp-y:  300 
svitch  A00END2  delay:  0  not  debounced  manufacturer:  "  " 
position:  OFF  conp-z:  480  conp-y:  200 
svitch  ADLEND3  delay:  0  not  debounced  manufacturer:  "  " 
position:  ON  conp-z:  480  conp-y:  100 
svitch  AD0END4  delay:  0  not  debounced  manufacturer:  "  " 
position:  OFF  conp-z:  360  conp-y:  400 
svitch  AUGENDl  delay:  0  not  debounced  manufacturer:  "  " 
position:  ON  conp-z:  360  conp-y:  100 
svitch  AUGEND2  delay:  0  not  debounced  manufacturer:  "  " 
position:  OFF  conp-z:  240  conp-y:  400 
svitch  AUGEND3  delay:  0  not  debounced  manufacturer:  "  " 
position:  OFF  conp-z:  240  conp-y:  300 
svitch  AUGEND4  delay:  0  not  debounced  manufacturer:  "  " 
position:  ON  conp-z:  240  conp-y:  200 
led  CARRY-OUT  manufacturer:  "  "  color:  RED  conp-z:  240 
conp-y:  100 

led  S8  manufacturer:  "  "  color:  RED  conp-z:  120  conp-y:  400 

led  S4  manufacturer:  "  "  color:  RED  conp-z:  120  conp-y:  300 

led  S2  manufacturer:  "  "  color:  RED  conp-z:  120  comp-y:  200 
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l«d  SI  manufactur«r : 
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color:  RED  cob^-x:  120  coBq>-y:  100 


a  7  BINARY-ARRAY-MULTIPLIERl  Application 

This  application  implements  a  binary  £Lrray  multiplier  as  a  top  level  subsystem,  composed  of 
“and”  gates,  “not”  gates,  switches,  LEDs,  and  2  half-adder  subsystems,  each  of  which  is  composed 
of  “and”  gates,  “or”  gates,  and  “not”  gates. 

application  definition  BINARY-ARRIY-MULTIPLIERI 
execution-mode :  NOM-EVENT-DRIVEN-SEQUENTIAL 
application  BINARY-ARRAY-MULTIPLIERl  is  controls: 

BIN-AR-MULT  update  procedure:  update  BIN-AR-NULT 
switch  A-ZERO  delay:  0  not  debounced  manufacturer:  ”  " 
position:  ON  comp-x:  lOS  comp-y:  517 
switch  A-ONE  delay:  0  not  debounced  manufacturer:  "  " 
position:  OFF  comp-x:  106  comp-y:  412 
switch  B-ZERO  delay:  0  not  debounced  manufacturer:  "  " 
position:  ON  comp-x:  104  comp-y:  308 
switch  B-ONE  delay:  0  not  debounced  manufacturer:  "  ” 
position:  OFF  coiq>-x:  103  comp-y:  194 
led  C-ZERO  manufacturer:  "  "  color:  RED  con^-x:  572 
comp-y:  301 

led  C-ONE  manufacturer:  "  "  color:  RED  comp-x:  583 
comp-y :  399 

led  C-TWO  manufacturer:  "  "  color:  RED  comp-x:  591 
comp-y :  528 

led  C-THREE  manufacturer:  "  "  color:  RED  cos^-x:  581 
comp-y :  183 

and-gate  AND-Al-Bl  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  comp-x:  282  comp-y:  178 
and-gate  AND-Al-BO  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  comp-x:  285  comp-y:  404 
and-gate  AND-AO-Bl  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  comp-x:  296  comp-y:  511 
and-gate  AND-AO-BO  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  comp-x:  280  comp-y:  297 
and-gate  HA-l-ANDl  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  comp-x:  107  comp-y;  68 
and-gate  HA-1-AND2  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level;  0.0  con^-x:  106  comp-y:  153 
or-gate  HA-l-OR  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level;  0.0  con^-x:  244  comp-y:  122 
not-gate  HA-l-NOT  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  comp-x:  363  comp-y:  126 
and-gate  HA-2-AND1  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  coiq>-x:  122  con^-y;  99 
and-gate  HA-2-AND2  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  coiq>-x:  113  comp-y:  197 
or-gate  BA-2-0R  delay:  0  not  mil-spec  manufacturer: 
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po««r  level:  0.0  coiap-z:  237  coo^-y:  156 
not-gate  HA-2-N0T  delay:  0  ie  mil-spec  manufacturer: 

power  level:  0.0  coop-x:  352  coo^-y:  160 
not-gate  NOT-X-HAl  delay:  0  not  mil-spec  manufacturer:  "  “ 
power  level:  0.0  cosqp-x:  440  coa^-y:  411 
not-gate  NOT-Y-HAl  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  comp-x:  439  comp-y:  510 
not-gate  N0T-X-HA2  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  con^-x:  116  comp-y:  72 
not-gate  N0T-Y-HA2  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  coii^>-x:  439  comp-y:  176 
subsystem  BIN-iR-MULT  is  controls: 

HA-1.  HA-2.  AND-Al-Bl.  AND-Al-BO,  AND-AO-Bl.  AMD-AO-BO. 
A-ZERO.  A-ONE.  B-ZERO.  B-ONE.  C-ZERO.  C-ONE,  C-TWO. 
C-THREE.  NOT-X-HAl.  NOT-Y-HAl.  N0T-X-HA2.  M0T-Y-HA2 


imports : 

INI  SIGNAL  BOOLEAN  HA-l-ANDl  (  OUTl  BIN-AR-MULT  NOT-X-HAl 
)  in^ort-path:  (  BIN-AR-NULT  HA-1  )  import-owner:  HA-1 
IN2  SIGNAL  BOOLEAN  HA-l-ANDl  (  OUTl  BIN-AR-MULT  NOT-Y-HAl 
)  import-path:  (  BIN-AR-MULT  HA-1  )  isport-owner :  HA-1 
INI  SIGNAL  BOOLEAN  HA-1-AND2  (  OUTl  BIN-AR-MULT  AND-Al-BO 
)  import-path:  (  BIN-AR-MULT  HA-1  )  inport-owner:  HA-1 
IN2  SIGNAL  BOOLEAN  HA-1-AND2  (  OUTl  BIN-AR-MULT  AND-AO-Bl 
)  import-path:  (  BIN-AR-MULT  HA-1  )  inport-owner:  HA-1 
INI  SIGNAL  BOOLEAN  HA-l-OR  (  OUTl  HA-l  HA-l-ANDl 

)  import-path:  (  BIN-AR-MULT  HA-1  )  inport-owner :  HA-1 
IN2  SIGNAL  BOOLEAN  HA-l-OR  (  OUTl  HA-1  HA-1-AND2 

)  import-path:  (  BIN-AR-MULT  HA-1  )  inport-owner:  HA-1 
INI  SIGNAL  BOOLEAN  HA-l-NOT  (  OUTl  HA-1  HA-l-OR 

)  import-path:  (  BIN-AR-MULT  HA-1  )  inport-owner:  HA-1 
INI  SIGNAL  BOOLEAN  HA-2-AND1  (  OUTl  BIN-AR-MULT  N0T-X-HA2 
)  import -path:  (  BIN-AR-MULT  HA-2  )  inport-owner:  HA-2 
IN2  SIGNAL  BOOLEAN  HA-2-AND1  (  OUTl  BIN-AR-MULT  N0T-Y-HA2 
)  inport-path:  (  BIN-AR-MULT  HA-2  )  inport-owner:  HA-2 
INI  SIGNAL  BOOLEAN  HA-2-AND2  (  OUTl  HA-1  HA-1-AND2 

)  inport-path:  (  BIN-AR-MULT  HA-2  )  inport-owner:  HA-2 
IN2  SIGNAL  BOOLEAN  HA-2-AND2  (  OUTl  BIN-AR-NULT  AND-Al-Bl 
)  import -path:  (  BIN-AR-MULT  HA-2  )  inport-owner:  HA-2 
INI  SIGNAL  BOOLEAN  HA-2-0R  (  OUTl  EA-2  HA-2-AND1 

)  import-path:  <  BIN-AR-MULT  HA-2  )  inport-owner:  HA-2 
IN2  SIGNAL  BOOLEAN  HA-2-0R  (  OUTl  HA-2  HA-2-AND2 

)  inport-path:  (  BIN-AR-NULT  HA-2  )  inport-owner:  HA-2 
INI  SIGNAL  BOOLEAN  HA-2-N0T  (  OUTl  HA-2  HA-2-0R 

)  inport-path:  (  BIN-AR-MULT  HA-2  )  inport-owner:  HA-2 
INI  SIGNAL  BOOLEAN  N0T-Y-HA2  (  OUTl  BIN-AR-MULT  AND-Al-Bl 
)  inport-path:  <  BIN-AR-NULT  )  inport-owner:  BIN-AR-MULT 
INI  SIGNAL  BOOLEAN  N0T-X-HA2  (  OUTl  HA-1  HA-1-AND2 

)  inport-path:  (  BIN-AR-MULT  )  inport-owner:  BIN-AR-MULT 
INI  SIGNAL  BOOLEAN  NOT-Y-HAl  (  OUTl  BIN-AR-MULT  AND-AO-Bl 
)  inport-path:  (  BIN-AR-MULT  )  import-owner:  BIN-AR-NULT 
INI  SIGNAL  BOOLEAN  NOT-X-HAl  (  OUTl  BIN-AR-MULT  AND-Al-BO 
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)  iiq>ort-path:  (  BIN-AR-MULT  )  ia^ort-OHnar :  BIN-AR-NULT 
INI  SIGNAL  BOOLEAN  C-THREE  (  OOTl  HA-2  BA-2-AND2 

)  i]q>ort-path:  (  BIN-AR-MULT  )  is^ort-omar:  BIN-AR-MOLT 
INI  SIGNAL  BOOLEAN  C-TWO  (  OUTl  HA-2  HA-2-N0T 

)  import-path:  (  BIN-AR-MULT  )  import -omar:  BIN-AR-MULT 
INI  SIGNAL  BOOLEAN  C-ONE  (  OUTl  HA-1  HA-l-NOT 

)  iiq>ort-path:  (  BIN-AR-MULT  )  io^ort-oimar :  BIN-AR-MULT 
INI  SIGNAL  BOOLEAN  C-ZERO  (  OUTl  BIN-AR-NULT  AND-AO-BO 
)  import -path:  (  BIN-AR-NULT  )  import-omar:  BIN-AR-NULT 
IM2  SIGNAL  BOOLEAN  AND-AO-BO  (  OUTl  BIN-AR-MULT  B-ZERO 
)  import-path:  (  BIN-AR-NULT  )  is^ort-ownar :  BIN-AR-NULT 
INI  SIGNAL  BOOLEAN  AND-AO-BO  (  OUTl  BIN-AR-NULT  A-ZERO 
}  import-path:  (  BIN-AR-NULT  )  in^ort-ovnar:  BIN-AR-NULT 
IN2  SIGNAL  BOOLEAN  AND-AO-Bl  (  OUTl  BIN-AR-NULT  B-ONE 
)  iiq>ort-path :  (  BIN-AR-MULT  )  import-ownar :  BIN-AR-MULT 
INI  SIGNAL  BOOLEAN  AND-AO-Bl  (  OUTl  BIN-AR-NULT  A-ZERO 
)  import-path:  (  BIN-AR-MULT  )  in5>ort-oimar :  BIN-AR-MULT 
IN2  SIGNAL  BOOLEAN  AND-Al-BO  (  OUTl  BIN-AR-MULT  B-ZERO 
)  import-path:  (  BIN-AR-MOLT  )  iiqport-oimar :  BIN-AR-MOLT 
INI  SIGNAL  BOOLEAN  AND-Al-BO  (  OUTl  BIN-AR-NULT  A-ONE 
)  import -path:  (  BIN-AR-MULT  )  import-oimar :  BIN-AR-MULT 
IN2  SIGNAL  BOOLEAN  AND-Al-Bl  (  OUTl  BIN-AR-MULT  B-ONE 
)  import-path:  (  BIN-AR-MULT  )  iaport-oimar :  BIN-AR-MULT 
INI  SIGNAL  BOOLEAN  AND-Al-Bl  (  OUTl  BIN-AR-NULT  A-ONE 
)  io^ort-path:  <  BIN-AR-MULT  )  import-omar:  BIN-AR-MULT 
exports: 

OUTl  SIGNAL  BOOLEAN  HA-l-ANDl 

export-path:  (  BIN-AR-MULT  HA-1  )  export-omer:  HA-1 
OUTl  SIGNAL  BOOLEAN  HA-1-AND2 

export-path:  (  BIN-AR-MULT  HA-1  )  export-omer:  HA-1 
OUTl  SIGNAL  BOOLEAN  HA-l-OR 

export -path:  (  BIN-AR-MULT  HA-1  )  export-omer:  HA-1 
OUTl  SIGNAL  BOOLEAN  HA-l-NOT 

export-path:  (  BIN-AR-MULT  HA-1  )  export-omer:  HA-1 
OUTl  SIGNAL  BOOLEAN  HA-2-AND1 

export-path:  (  BIN-AR-MULT  HA-2  )  export-omer:  HA-2 
OUTl  SIGNAL  BOOLEAN  HA-2-AND2 

export-path:  (  BIN-AR-MOLT  HA-2  )  export-omer:  HA'2 
OUTl  SIGNAL  BOOLEAN  HA-2-0R 

export-path:  <  BIN-AR-MULT  HA-2  )  export-omer:  HA-2 
OUTl  SIGNAL  BOOLEAN  HA-2-N0T 

export-path:  (  BIN-AR-MOLT  HA-2  )  export-omer:  HA-2 
OUTl  SIGNAL  BOOLEAN  N0T-Y-HA2 

export -path:  (  BIN-AR-MULT  )  export-omer:  BIN-AR-MOLT 
OUTl  SIGNAL  BOOLEAN  N0T-X-HA2 

export-path:  (  BIN-AR-MULT  )  export-omer:  BIN-AR-MOLT 
OUTl  SIGNAL  BOOLEAN  NOT-Y-HAl 


export-path:  (  BIN-AR-MULT  )  export-omer:  BIN-AR-MOLT 
OUTl  SIGNAL  BOOLEAN  NOT-X-HAl 

export-path:  (  BIN-AR-MOLT  )  export-omer;  BIN-AR-MOLT 
OUTl  SIGNAL  BOOLEAN  B-ONE 
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•xport-path:  (  BIH-iR-MDLT  )  •xport-own«r :  BIM-iB-MOLT 
OUTl  SIGNAL  BOOLEAN  B-ZERO 

•xport-path:  (  BIN-AR-MOLT  )  •xport-ownor :  BIN-AB-MOLT 
OUTl  SIGNAL  BOOLEAN  A-ONE 

•xport-path:  (  BIN-AR-MOLT  )  axport-ownor :  BIN-AR-MOLT 
OOTl  SIGNAL  BOOLEAN  A-ZERO 

•xport-path:  (  BIN-AR-MOLT  )  axport-ownor :  BIN-AR-MOLT 
OUTl  SIGNAL  BOOLEAN  AND-AO-BO 

•xport-path:  (  BIN-AR-MOLT  )  •xport-ownor :  BIN-AB-MOLT 
OOTl  SIGNAL  BOOLEAN  AND-AO-Bl 

•xport-path:  (  BIN-AR-MOLT  )  axport-oimor :  BIN-AB-MOLT 
OOTl  SIGNAL  BOOLEAN  AND-Al-BO 

•xport-path:  (  BIN-AR-MOLT  )  axport-ownor:  BIN-AB-MOLT 
OUTl  SIGNAL  BOOLEAN  AND-Al-Bl 

•xport-path:  (  BIN-AR-MOLT  )  axport-ownor:  BIN-AB-MOLT 
initializo  procadura:  updata  procodura: 
updata  A-ZERO  updata  A-ONE  updata  B-ZERO  updata  B-ONE 
updata  AND-AO-Bl  updata  AND-AO-BO  updata  AND-Al-Bl 
updata  AND-Al-BO  updata  NOT-X-HAl  updata  NOT-Y-HAl 
updata  N0T-X-HA2  updata  N0T-Y-HA2  updata  HA-1  updata  HA-2 
updata  C-ZERO  updata  C-ONE  updata  C-TWO  updata  C-THREE 
subayatam  HA-1  ia  controla: 

HA-l-ANDl,  HA-1-AND2,  HA-l-OR,  HA-l-NOT  importa:  oxporta: 
initializo  procadura:  updata  procadura: 
updata  HA-l-ANDl  updata  HA-1-AND2  updata  HA-l-OR 
updata  HA-l-NQT 
comp-x:  442  con^-y:  615 
aubayatom  HA-2  ia  controla: 

HA-2-AND1,  HA-2-AND2,  HA-2-0R,  HA-2-N0T  iJi5>orta:  oxporta: 
initializo  procadura:  updata  procadura: 
updata  HA-2-AND1  updata  HA-2-AND2  updata  HA-2-OR 
updata  HA-2-N0T 
con^-x:  157  comp-y:  613 


C.8  BINARY-ARRAY-MULTIPLIERS  Application 

This  application  implements  a  binary  array  multiplier  similar  to  the  previous  application, 
except  that  primitive  half-adders  are  used  instead  of  lower-level  subsystems  composed  of  primitive 
gates. 

application  definition  BINARY-ARRAY-MOLTIPLIER2 
•xacution-moda :  NON-EVENT-DRIVEN-SEQOENTIAL 
application  BINARY-ARRAY-N0LTIPLIER2  is  controls:  DO-BAM 
update  procadura:  updata  DO-BAM 
and-gata  AOBO  delay:  0  not  mil-spac  manufacturer:  "  " 
power  level:  0.0  comp-x:  119  conp-y:  395 
and-gata  AIBO  delay:  0  not  mil-spac  manufacturer:  "  " 
power  level:  0.0  con^-x:  118  con^-y:  100 
and-gata  AOBl  delay:  0  not  mil-spac  manufacturer: 
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power  level:  0.0  coxup-x:  119  cojop-j:  198 
and-gate  ilBl  delay:  0  not  mil-spec  manufacturer: 

power  level:  0.0  coiqt-z:  120  co]q>-y:  300 
half -adder  HA-PRIMl  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  coi^-z:  367  coiq>-y:  250 
half -adder  HA-PRIM2  delay:  0  not  mil -spec  manufacturer:  "  " 
power  level:  0.0  comp-z:  241  con^-y:  154 
subsystem  BINARY-ARRAY-MULT  is  controls: 

AOBO,  AIBO,  AOBl.  AlBl.  HA-PRINl.  HA-PRIM2  iiq>ort8:  ezports: 
initialize  procedure:  update  procedure: 
update  AOBl  update  AOBO  update  AlBl  update  AIBO 
update  HA-PRIM2  update  HA-PRINl 
switch  A-ZERO  delay:  0  not  debounced  manufacturer:  "  " 
position:  ON  comp-z:  360  comp-y:  200 
switch  A-ONE  delay:  0  not  debounced  manufacturer:  "  " 
position:  ON  con^-z:  360  coiq)'y:  100 
switch  B-ZERO  delay:  0  not  debotuced  manufacturer:  "  " 
position:  ON  comp-z:  240  comp-y:  300 
switch  B-ONE  delay:  0  not  debounced  manufacturer:  “  " 
position:  ON  comp-z:  240  coiq)-y:  200 
led  C-ZERO  manufacturer:  "  "  color:  RED  con^-z:  240 
comp-y :  100 

led  C-ONE  manufacturer:  "  "  color:  RED  comp-z:  120 
conp-y:  300 

led  C-TWO  manufacturer:  "  "  color:  RED  comp-z:  120 
comp-y:  200 

led  C-THREE  manufacturer:  "  "  color:  RED  con5)-z:  120 
cojq)-y :  100 

subsystem  DO-BAM  is  controls: 

A-ZERO,  A-ONE,  B-ZERO,  B-ONE,  C-ZERO,  C-ONE,  C-TWO, 

C-THREE,  BINARY-ARRAY-MULT 
imports : 

IN2  SIGNAL  BOOLEAN  HA-PRIM2  (  OUTl  BINARY-ARRAY-NULT  AIBO 

)  inport-path:  (  DO-BAH  BINARY-ARRAY-MULT  )  inport-owner: 

BINARY-ARRAY-MULT 

INI  SIGNAL  BOOLEAN  HA-PRIM2  (  OUTl  BINARY-ARRAY-NULT  AOBl 
)  import -path:  (  DO-BAN  BINARY-ARRAY-NULT  )  inport-owner: 

BINARY-ARRAY-MULT 

IN2  SIGNAL  BOOLEAN  HA-PRIMl  (  C  BINARY-ARRAY-MULT  HA-PRIM2 
)  inport-path:  (  DO-BAM  BINARY-ARRAY-MULT  )  inport-owner: 

BINARY-ARRAY-MULT 

INI  SIGNAL  BOOLEAN  HA-PRIMl  (  OUTl  BINARY-ARRAY-MULT  AlBl 
)  inport-path:  (  DO-BAN  BINARY-ARRAY-NULT  )  inport-owner: 

BINARY-ARRAY-MULT 

IN2  SIGNAL  BOOLEAN  AlBl  (  OUTl  DO-BAN  B-ONE 

)  inport-path:  (  DO-BAM  BINARY-ARRAY-MULT  )  inport-owner: 

BINARY-ARRAY-NULT 

INI  SIGNAL  BOOLEAN  AlBl  (  OUTl  DO-BAM  A-ONE 

)  inport-path:  (  DO-BAM  BINARY-ARRAY-MULT  )  inport-owner: 

BINARY-ARRAY-MULT 

IN2  SIGNAL  BOOLEAN  AOBl  (  OUTl  DO-BAM  B-ONE 
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)  iiqwrt-path:  (  DO-BIN  BIMARY-ABRAY-NULT  )  iiqwrt-oinier : 
BZKiRY-iRRAY-MULT 

INI  SIGNAL  BOOLEAN  AOBl  (  OUTl  DO-BAN  A-ZERO 

)  uq)ort-path:  (  DO-BAM  BINARY-ARRAY-NULT  )  iiq>ort-oimer: 
BINARY-ARRAY-NDLT 

IN2  SIGNAL  BOOLEAN  AIBO  (  OUTl  DO-BAN  B-ZERO 

)  isqport-patli:  (  DO-BAN  BINARY-ARRAY-NULT  )  iiiq>ort-OHnar : 
BINARY-ARRAY-NULT 

INI  SIGNAL  BOOLEAN  AIBO  (  OUTl  DO-BAN  A-ONE 

)  u^ort-path:  (  DO-BAN  BINARY-ARRAY-NULT  )  ijiq>ort-oBnar: 
BINARY-ARRAY-NULT 

IN2  SIGNAL  BOOLEAN  AOBO  (  OUTl  DO-BAN  B-ZERO 

)  in^ort-path:  (  DO-BAN  BINARY-ARRAY-NULT  )  i]iq>ort-ownar: 
BINARY-ARRAY-NULT 

INI  SIGNAL  BOOLEAN  AOBO  (  OUTl  DO-BAN  A-ZERO 
)  import-path:  (  DO-BAN  BINARY-ARRAY-NULT  )  io^ort-oimer : 
BINARY-ARRAY-NULT 

INI  SIGNAL  BOOLEAN  C-THREE  (  C  BINARY-ARRAY-NULT  HA-PRINl 
)  in^ort-path:  (  DO-BAN  )  in^ort-oaner :  DO-BAH 
INI  SIGNAL  BOOLEAN  C-TWO  (  S  BINARY-ARRAY-NULT  HA-PRINl 
)  import -path:  (  DO-BAN  )  import-oimer :  DO-BAN 
INI  SIGNAL  BOOLEAN  C-ONE  (  S  BINARY-ARRAY-NULT  HA-PRIN2 
)  import-path:  (  DO-BAN  )  i]q)ort-oimar :  DO-BAN 
INI  SIGNAL  BOOLEAN  C-ZERO  (  OUTl  BINARY-ARRAY-NULT  AOBl 
)  io^ort-path:  (  DO-BAN  )  import-omer :  DO-BAN 
azports: 

C  SIGNAL  BOOLEAN  HA-PRIN2 

«xport-path:  (  DO-BAN  BINARY-ARRAY-NULT  )  export-oimor : 

BINARY-ARRAY-NULT 
S  SIGNAL  BOOLEAN  HA-PRIN2 

«zport-path:  (  DO-BAN  BINARY-ARRAY-NULT  )  export -o«n«r: 
BINARY-ARRAY-NULT 
C  SIGNAL  BOOLEAN  HA-PRINl 

export -path:  (  DO-BAN  BINARY-ARRAY-NDLT  )  export -ovner: 
BINARY-ARRAY-NULT 
S  SIGNAL  BOOLEAN  HA-PRINl 

export-path:  (  DO-BAN  BINARY-ARRAY-NULT  )  export-ovner : 
BINARY-ARRAY-NULT 
OUTl  SIGNAL  BOOLEAN  AlBl 

export-path:  (  DO-BAN  BINARY-ARRAY-NULT  )  export-owner: 
BINARY-ARRAY-NULT 
OUTl  SIGNAL  BOOLEAN  AOBl 

export-path:  (  DO-BAN  BINARY-ARRAY-NULT  )  export-owner: 
BINARY-ARRAY-NDLT 
OUTl  SIGNAL  BOOLEAN  AIBO 

export-path:  (  DO-BAN  BINARY-ARRAY-NDLT  )  export-owner: 
BINARY-ARRAY-NDLT 
OUTl  SIGNAL  BOOLEAN  AOBO 

export -path:  (  DO-BAN  BINARY-ARRAY-NULT  )  export-owner: 
BINARY-ARRAY-NULT 
OUTl  SIGNAL  BOOLEAN  B-ONE 
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•xport-path;  (  DO-BAN  )  axport-om^r:  DO-BAN 
OUTl  SIGNAL  BOOLEAN  B-ZERO 

•xport-path:  (  DO-BAN  )  axport-omor ;  DO-BAN 
OOTl  SIGNAL  BOOLEAN  A-ONE 

export -path:  (  DO-BAN  )  axport-ovner;  DO-BAN 
OlTTl  SIGNAL  BOOLEAN  A-ZERO 

•xport-path:  (  DO-BAN  )  export-ovner :  DO-BAN 
initieilize  procedure:  update  procedure: 
update  A-ONE  update  A-ZERO  update  B-ONE  update  B-ZERO 
update  BINARY-ARRAY-NULT  update  C-THREE  update  C-TWO 
update  C-ONE  update  C-ZERO 


C.9  THREE-TO-EIGHT-DECODER  Application 

This  application  composes  “and”  gates  and  “not”  gates  into  a  subsystem  implementation  of 
a  3-to-8  decoder. 

application  definition  THREE-TO-EIGHT-DECODER 
execution-mode :  NON-EVENT-DRIVEN-SEQDENTIAL 
application  THREE-TO-EIGHT-DECODER  is  controls:  DRIVER 
update  procedure:  update  DRIVER 
svitch  SWITCH-IN-X  delay:  0  not  debounced  manufacturer:  "  " 
position:  ON  con^-x:  100  conqp-y:  100 
switch  SWITCH- IN-Y  delay:  0  not  debounced  manufacturer:  "  " 
position:  ON  comp-x:  100  comp-y:  200 
switch  SWITCH- IN-Z  delay:  0  not  debounced  manufacturer:  "  " 
position:  OFF  comp-x:  100  con^-y:  300 
led  NO  manufacturer:  "  "  color:  RED  comp-x:  300  comp-y:  100 

led  N1  manufacturer:  "  "  color:  RED  comp-x:  300  comp-y:  200 

led  N2  manufacturer:  "  "  color:  RED  comp-x:  300  comp-y:  300 

led  H3  manufacturer:  "  "  color:  RED  comp-x:  300  con^-y:  400 

led  N4  manufacturer:  "  "  color:  RED  comp-x:  300  comp-y:  500 

led  NS  manufacturer:  "  "  color:  RED  comp-x:  300  comp-y:  600 

led  N6  manufacturer:  "  "  color:  RED  con^-x:  300  conqp-y:  700 

led  H7  manufacturer:  "  "  color:  RED  comp-x:  300  comp-y:  800 

subsystem  DRIVER  is  controls: 

SWITCH-IN-X,  SWITCH-IN-Y,  SWITCH-IN-Z,  NO,  HI,  N2,  N3,  H4, 

M5,  N6,  H7,  DECODERl 
in^orts : 

IN2  SIGNAL  BOOLEAN  AND-H7-B  (  ODTl  DRIVER  SWITCH-IN-X 

)  in^ort-path:  (  DRIVER  DECODERl  )  import-owner:  DECODERl 
INI  SIGNAL  BOOLEAN  AND-H7-B  (  OUTl  DECODERl  AND-N7-A 

)  import-path:  (  DRIVER  DECODERl  )  import-owner:  DECODERl 
IN2  SIGNAL  BOOLEAN  AND-H7-A  (  OOTl  DRIVER  SWITCH-IN-Y 

)  import -path:  (  DRIVER  DECODERl  )  io^ort-owner :  DECODERl 
INI  SIGNAL  BOOLEAN  AND-H7-A  (  OOTl  DRIVER  SWITCH-IN-Z 

)  import -path:  (  DRIVER  DECODEXl  }  import-owner:  DECODERl 
IN2  SIGNAL  BOOLEAN  AND-H6-B  (  OOTl  DRIVER  SWITCH-IN-X 

)  import-path:  (  DRIVER  DECODERl  )  import-owner:  DECODERl 
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IHl  SIGNAL  BOOLEAN  AND-M6-B  (  OOTi  DECODEHl  AND-M6-A 

)  import -path:  (  DRIVER  DECODERl  )  import - owner :  OECOOE311 
IN2  SIGNAL  BOOLEAN  AND-N6-A  (  OUTl  DRIVER  SWITCH-IN-Y 
)  import-path:  (  DRIVER  DECODERl  )  iaport-owner:  DECODERl 
INI  SIGNAL  BOOLEAN  AND-H6-A  (  OUTl  DECODERl  NOT-Z 

)  import-path:  (  DRIVER  DECODERl  )  import-owner:  DECODERl 
IN2  SIGNAL  BOOLEAN  AND-M5-B  (  OUTl  DRIVER  SWITCH-IN-X 
)  import-path:  (  DRIVER  DECODERl  )  import-owner:  DECODERl 
INI  SIGNAL  BOOLEAN  AND-N5-B  (  OUTl  DECODERl  AND-M5-A 

)  import-path:  (  DRIVER  DECODERl  )  iiq>ort -owner:  DECODERl 
IN2  SIGNAL  BOOLEAN  AND-MS-A  (  OUTl  DECODERl  NOT-Y 

)  import-path:  (  DRIVER  DECODERl  )  io^ort-owner :  DECODERl 
INI  SIGNAL  BOOLEAN  AND-H5-A  (  OUTl  DRIVER  SWITCH-IN-Z 

}  import-path:  (  DRIVER  DECODERl  )  i]iq[>ort-owner :  DECODERl 
IN2  SIGNAL  BOOLEAN  AND-M4-B  (  OUTl  DRIVER  SWITCH-IN-X 

}  in^ort-path:  (  DRIVER  DECODERl  )  iiq>ort-owner :  DECODERl 
INI  SIGNAL  BOOLEAN  AND-H4-B  (  OUTl  DECODERl  AND-M4-A 

)  import -path:  (  DRIVER  DECODERl  )  import-owner:  DECODERl 
IN2  SIGNAL  BOOLEAN  AND-M4-A  (  OUTl  DECODERl  NOT-Y 

)  import -path:  (  DRIVER  DECODERl  )  import - owner :  DECODERl 
INI  SIGNAL  BOOLEAN  AND-M4-A  (  OUTl  DECODERl  NOT-Z 

)  import-path:  (  DRIVER  DECODERl  )  import-owner:  DECODERl 
IN2  SIGNAL  BOOLEAN  AN0-M3-B  (  OUTl  DECODERl  NOT-X 

)  import-path:  <  DRIVER  DECODERl  )  import-owner:  DECODERl 
INI  SIGNAL  BOOLEAN  AND-H3-B  (  OUTl  DECODERl  AND-M3-A 

)  import-path:  (  DRIVER  DECODERl  )  import -owner:  DECODERl 
IN2  SIGNAL  BOOLEAN  AND-M3-A  (  OUTl  DRIVER  SWITCH-IN-Y 

)  import-path:  (  DRIVER  DECODERl  )  import-owner:  DECODERl 
INI  SIGNAL  BOOLEAN  AND-H3-A  (  OUTl  DRIVER  SWITCH-IN-Z 

)  import-path:  (  DRIVER  DECODERl  }  import-owner:  DECODERl 
IN2  SIGNAL  BOOLEAN  AND-M2-B  (  OUTl  DECODERl  NOT-X 

)  import -path:  (  DRIVER  DECODERl  )  import-owner:  DECODERl 
INI  SIGNAL  BOOLEAN  AND-M2-B  (  OUTl  DECODERl  AND-M2-A 

)  import-path:  (  DRIVER  DECODERl  )  import-owner:  DECODERl 
IN2  SIGNAL  BOOLEAN  AND-M2-A  (  OUTl  DRIVER  SWITCH-IN-Y 

)  import -path:  (  DRIVER  DECODERl  )  import-owner:  DECODERl 
INI  SIGNAL  BOOLEAN  AND-M2-A  (  OUTl  DECODERl  NOT-Z 

)  import-path:  (  DRIVER  DECODERl  }  import-owner:  DECODERl 
IN2  SIGNAL  BOOLEAN  AND-Nl-B  (  OUTl  DEXIODERl  NOT-X 

)  import-path:  (  DRIVER  DECODERl  )  import-owner:  DECODERl 
INI  SIGNAL  BOOLEAN  AND-Ml-B  (  OUTl  DECODERl  AND-Ml-A 

)  import-path:  (  DRIVER  DECODERl  )  import-owner:  DECODERl 
IN2  SIGNAL  BOOLEAN  AND-Ml-A  (  OUTl  DECODERl  NOT-Y 

}  import-path:  (  DRIVER  DECODERl  )  import-owner:  DECODERl 
INI  SIGNAL  BOOLEAN  AND-Ml-A  (  OUTl  DRIVER  SWITCH-IN-Z 

)  import-path:  (  DRIVER  DECODERl  )  import-owner:  DECODERl 
IN2  SIGNAL  BOOLEAN  AND-MO-B  (  OUTl  DECODERl  NOT-X 

)  import -path:  (  DRIVER  DECODERl  )  import-owner:  DECODERl 
INI  SIGNAL  BOOLEAN  AND-NO-B  (  OUTl  DECODERl  AND-MO-A 

)  import -path:  (  DRIVER  DECODERl  }  import - owner ;  DECODERl 
IN2  SIGNAL  BOOLEAN  AND-MO-A  (  OUTl  DECODERl  NOT-Y 
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)  io^ort-path:  (  DRIVER  DECODER!  }  u^ort-ownar:  DECODER! 
IN!  SIGNAL  BOOLEAN  AND-NO-A  (  OUT!  DECODER!  NOT-Z 

)  import-path:  (  DRIVER  DECODER!  }  i]q>ort-ovneT:  DECODER! 
IN!  SIGNAL  BOOLEAN  NOT-Z  (  OUT!  DRIVER  SWITCH-IN-Z 

)  i]q>ort-path:  (  DRIVER  DECODER!  )  insert -ovnar:  DECODER! 
IN!  SIGNAL  BOOLEAN  NOT-Y  (  OUT!  DRIVER  SWITCH-IN-Y 

)  import-path:  (  DRIVER  DECODER!  )  import-owner:  DECODER! 
IN!  SIGNAL  BOOLEAN  NOT-I  (  OUT!  DRIVER  SWITCH-IN-X 

)  import-path:  (  DRIVER  DECODER!  )  ii^ort-ovner :  DECODER! 
IN!  SIGNAL  BOOLEAN  H7  (  OUT!  DECODER!  AND-M7-B 
)  import-path:  (  DRIVER  )  import-owner:  DRIVER 
IN!  SIGNAL  BOOLEAN  M6  (  OUT!  DECODER!  AND-M6-B 
)  import-path:  (  DRIVER  }  io^ort - owner :  DRIVER 
IN!  SIGNAL  BOOLEAN  MS  (  OUT!  DECODER!  AND-M5-B 
}  import -path:  (  DRIVER  )  in^ort-owner :  DRIVER 
IN!  SIGNAL  BOOLEAN  M4  (  OUT!  DECODER!  AND-N4-B 
)  import-path:  (  DRIVER  }  in^ort-owner :  DRIVER 
IN!  SIGNAL  BOOLEAN  H3  (  OUT!  DECODER!  AND-M3-B 
)  import-path:  (  DRIVER  )  in^ort -owner :  DRIVER 
IN!  SIGNAL  BOOLEAN  M2  (  OUT!  DECODER!  AND-M2-B 
)  import -path:  (  DRIVER  )  import-owner:  DRIVER 
IN!  SIGNAL  BOOLEAN  M!  (  OUT!  DECODER!  AND-M!-B 
)  import -path:  (  DRIVER  )  iiq)ort-owner :  DRIVER 
IN!  SIGNAL  BOOLEAN  MO  (  OUT!  DECODER!  AND-MO-B 
)  import -path:  (  DRIVER  )  import-owner:  DRIVER 
exports : 

OUT!  SIGNAL  BOOLEAN  AND-M7-B 
export-path:  (  DRIVER  DECODER!  )  export-owner:  DECODER! 

OUT!  SIGNAL  BOOLEAN  AND-M7-A 

export-path:  (  DRIVER  DECODER!  )  export-owner:  DECODER! 
OUT!  SIGNAL  BOOLEAN  AND-N6-B 

export -path:  (  DRIVER  DECODER!  )  export-owner:  DECODER! 
OUT!  SIGNAL  BOOLEAN  AND-M6-A 

export -path:  (  DRIVER  DECODER!  )  export-owner:  DECODER! 
OUT!  SIGNAL  BOOLEAN  AND-MS-B 

export-path:  (  DRIVER  DECODER!  )  export-owner:  DECODER! 
OUT!  SIGNAL  BOOLEAN  AND-MS-A 

export-path:  (  DRIVER  DECODER!  )  export-owner:  DECODER! 
OUT!  SIGNAL  BOOLEAN  AND-N4-B 

export -path:  (  DRIVER  DECODER!  )  export -owner :  DECODER! 
OUT!  SIGNAL  BOOLEAN  AND-M4-A 

export-path:  (  DRIVER  DECODER!  )  export-owner:  DECODER! 
OUT!  SIGNAL  BOOLEAN  AND-N3-B 

export-path:  (  DRIVER  DECODER!  )  export-owner:  DECODER! 
OUT!  SIGNAL  BOOLEAN  AND-N3-A 

export-path:  (  DRIVER  DECODER!  )  export-owner:  DECODER! 
OUT!  SIGNAL  BOOLEAN  AND-N2-B 

export-path:  (  DRIVER  DECODER!  )  export-owner:  DECODER! 
OUT!  SIGNAL  BOOLEAN  AND-N2-A 

export-path:  (  DRIVER  DECODER!  }  export-owner:  DECODER! 
OUT!  SIGNAL  BOOLEAN  AND-M!-B 
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export-path:  (  DRIVER  DECOOERl  )  ezport-onter:  DECODERl 
OUTl  SIGNAL  BOOLEAN  AND-Nl-A 

export-path:  (  DRIVER  DECODERl  )  export-omer:  DECODERl 
OUTl  SIGNAL  BOOLEAN  AND-MO-B 

export-path:  (  DRIVER  DECODERl  )  export -owner:  DECODERl 
OUTl  SIGNAL  BOOLEAN  AND-MO-A 

export-path:  (  DRIVER  DECODERl  )  export-owner:  DECODERl 
OUTl  SIGNAL  BOOLEAN  NOT-Z 

export-path:  (  DRIVER  DECODERl  )  export-owner:  DECODERl 
OUTl  SIGNAL  BOOLEAN  NOT-Y 

export-path:  (  DRIVER  DECODERl  )  export-owner:  DECODERl 
OUTl  SIGNAL  BOOLEAN  NOT-X 

export-path:  (  DRIVER  DECODERl  )  export-owner:  DECODERl 
OUTl  SIGNAL  BOOLEAN  SWITCH-IN-Z 

export-path:  (  DRIVER  )  export-owner:  DRIVER 
OUTl  SIGNAL  BOOLEAN  SWITCH-IN-Y 

export -path:  (  DRIVER  )  export-owner:  DRIVER 
OUTl  SIGNAL  BOOLEAN  SWITCB-IN-X 

export -path:  (  DRIVER  )  export -owner:  DRIVER 
initialize  procedure:  update  procedure: 
update  SWITCH-IN-X  update  SWITCH-IN-Y  update  SWITCH-IN-Z 
update  DECODERl  update  MO  update  Ml  update  M2  update  M3 
update  M4  update  MS  update  M6  update  M7 
not-gate  NOT-X  delay:  0  not  mil-spec  manufacturer:  ”  ” 
power  level:  0.0  con^-x:  600  con5>-y:  650 
not-gate  NOT-Y  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  comp-x:  200  comp-y:  650 
not-gate  NOT-Z  delay:  0  not  mil-spec  manufacturer:  ”  " 
power  level:  0.0  con5)-x:  200  conqi-y:  250 
and-gate  AND-MO-A  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  comp-x:  400  con5)-y:  800 
and-gate  AND-MO-B  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  comp-x:  800  comp-y:  800 
and-gate  AND-Ml-A  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  con^-x:  400  con^-y:  700 
and-gate  AND-Ml-B  delay:  0  not  mil-spec  manxif acturer :  "  " 
power  level:  0.0  comp-x:  800  comp-y:  700 
and-gate  AND-M2-A  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  con5>-x:  400  comp-y:  600 
and-gate  AND-M2-B  delay:  0  not  m* 1-spec  manufacturer:  "  " 
power  level:  0.0  cony-x:  800  con5>-y:  600 
and-gate  AND-M3-A  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  comp-x:  400  coii5>-y:  500 
euid-gate  AND-M3-B  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  corq)-x:  800  comp-y:  500 
and-gate  AND-M4-A  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  con5>-x:  400  conp-y;  400 
etnd-gate  AND-M4-B  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  conp-x:  800  conp-y:  400 
and-gate  AND-M5-A  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  comp-x:  400  comp-y:  300 
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and-gats  AND-MS-B  delay:  0  not  mil-spec  manufacturer: 

power  level:  0.0  coiq>-z:  800  cong>-y:  300 
and-gate  AND-M6-i  delay:  0  not  mil-spec  manufacturer:  "  '' 
power  level:  0.0  coiiq>-z:  400  conq>-y:  200 
and-gate  AND-M6-B  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  comp-z:  800  comp-y:  200 
and-gate  AND-M7-A  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  comp-z:  400  comp-y:  100 
and-gate  AND-M7-B  delay:  0  not  mil-spec  manufacturer:  "  " 
power  level:  0.0  comp-z:  800  comp-y:  100 
subsystem  DECODERl  is  controls: 

NOT-X,  NOT-Y,  NOT-Z,  AND-MO-A,  AND-MO-B,  AND-Ml-A, 

AND-Ml-B,  AND-M2-A.  Airo-M2-B.  AND-M3-A,  A»D-M3-B.  AND-M4-A. 
AND-M4-B,  AND-MS-A,  AND-M6-B,  AND-H6-A,  AND-M6-B,  AND-M7-A. 
AND-M7-B 

imports:  ezports:  initialize  procedure:  update  procedure: 
update  NOT-X  update  NOT-Y  update  NOT-Z  update  AND-MO-A 
update  AND-MO-B  update  AND-Ml-A  update  AND-Ml-B 
update  AND-M2-A  update  AND-M2-B  update  AND-N3-A 
update  AND-M3-B  update  AND-M4-A  update  AND-M4-B 
update  AND-N5-A  update  AND-M5-B  update  AND-N6-A 
update  AND-M6-B  update  AND-M7-A  update  AND-M7-B 
comp-z:  500  comp-y:  200 
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Appendix  D.  Sample  Session  :  Populating  OODBMS  With  Domain  Knowledge 

This  appendix  conteiins  a  sample  session  for  using  the  ITASCA  Active  Data  Editor 
to  populate  the  Domain-Definition  Meta-Model  with  a  subset  of  the  logic  circuits  domain. 
The  portion  of  the  logic  circuits  domain  implemented  in  this  appendix  is  shaded  and  labeled 
“sample  session”  in  Figme  D.l.  The  rest  of  the  logic  circmts  domain  was  implemented  in 
the  Scune  way,  but  is  not  shown  in  this  appendix. 

Figure  D.2  is  an  instance  diagram  of  the  Domain-Definition  Meta-Model  for  the 
subset  of  the  logic  circuits  domain  we  instantiate  in  this  appendix.  We  have  found  it 
best  to  start  at  the  bottom  of  the  instance  diagram  and  work  toward  the  top  because  the 
lower-level  objects  generally  need  to  be  put  into  some  relationship  attribute  of  a  higher-level 
object.  For  instance,  you  must  instantiate  the  DATA-OBJECT  classes  in  the  lower  right 
hand  comer  of  Figure  D.2  before  you  can  completely  define  the  CONCRETE  class  above 
it.  Those  DATA-OBJECT  instances  are  identified  by  their  unique  object  identifier  in  their 
parent  CONCRETE  classes  ICO-DATA-OBJECTS  attribute. 
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Figure  D.l  Sample  Subset  of  Logic  Circuits  Domsdn 


Fui^Type^(OOJ-ActM4J^ 

Kind{nun(OCt^Alrliule,(XX)-(>^ 


Figure  D.2  Instwce  Diagram  for  Sample  Subset  of  Logic  Circuits  Domain 
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D.l  Start  a  Session 


When  the  ITASCA  ADE  is  invoked,  the  window  depicted  in  Figure  D.3  is  displayed. 
The  first  thing  to  do  after  invoking  the  ADE  is  to  move  to  the  appropriate  database  in 
which  to  do  your  work.  This  is  done  by  clicking  on  the  “Private”  icon  on  the  menu  bar  and 
selecting  from  the  list  of  databases  that  will  be  displayed  in  a  sub-menu.  As  you  can  see 
from  the  message  on  the  window,  we  are  currently  connected  to  private  database  thirteen 
to  do  this  work.  Once  you  are  in  the  appropriate  database,  you  should  commit  the  “move” 
transaction  by  first  clicking  on  “ITASCA”  and  then  clicking  on  “Commit”  in  the  sub-menu 
that  comes  up. 


ITASCA  Distributed  ODBMS 
GUI  Active  Data  Editor 
Release2DD  (OSF/Motif  1.1  J) 


Figure  D.3  ITASCA  ADE 
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D.2  Instantiate  Instances  of  the  DATA-OBJECT  Class 

We  start  by  instantiating  all  the  DATA-OBJECT  classes  (attributes,  inputs,  and 
outputs)  shown  in  Figure  D.2.  Click  on  “View”  in  Figure  D.3,  then  when  the  sub-menu 
appears  click  on  “Schema”  to  cause  the  window  in  Figmre  D.4  to  appear.  Click  on  “Filter” 
in  Figure  D.4  to  get  the  classes  in  the  window  to  the  left  of  the  “Filter”  to  display,  and 
select  “DATA-OBJECT-Vl”  as  illustrated.  Click  on  “Object”  in  the  menu  bar,  and  “New 
Inst2uice”  in  the  sub-menu  to  bring  up  a  blank  template  for  defining  an  instance  of  DATA- 
OBJECT  Class.  Figure  D.5  is  a  New  Instance  template  filled  in  for  the  manufacturer 
attribute  depicted  in  Figure  D.l  and  Figure  D.2.  We  go  through  this  same  process  for 
the  rest  of  the  DATA-OBJECT  instances  depicted  in  Figure  D.2.  Figure  D.6  through 
Figmre  D.ll  illustrate  the  creation  of  the  rest  of  the  (attribute,  input,  and  output)  DATA- 
OBJECT  instances. 


CLASS 


CONCRETE-Vl 

CONFIO-OBJ 

COUNTER 


DECODER 

ITASCA-ADE:;DESKTOP-IC 

DISK-STREAM 


NAME 

TYPE 

INIT-VAL 

CATEGORY 

DESCRIPTION 


MAKE-ICON-ATTR-ST? 
MA  KE-EDIT- ATTR-STR 
LONG-NAME 
MAKE-OCU-STMT 
SHOW-INSTANCE-DAT. 


Abitnct  NIL 
VentauUK  NIL 
Decument  NIL 


Figxire  D.4  Selecting  the  DATA-OBJECT  Class 
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i<pATA-o>ieeT-vi  ia<5aB«87) 


miAuftccutv 


non«  «p«cditd 


71u«  u  ch«  a«m«  of  tha  compan 


Figure  D.5  Instantiating  the  Manufacturer  Attribute 


boaUan 


gata  (abatract-claaa)  2 


Figure  D.6  Instantiating  the  MilSpec?  Attribute 
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g«tc  (•bftVACt-cUtt)  1 


Figure  D.7  Instantiating  the  Delay  Attribute 


pATA-Qg^sor-^  ii4smza7^;^l 


power-levtl 


g«t«  («bctr«ct-  daf f)  3 


Figure  D.8  Instantiating  the  PowerLevel  Attribute 


D-7 


Figure  D.9  Instantiating  the  Ini  Input 


Figure  D.IO  Instantiating  the  In2  Input 
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Figiire  D.ll  Instantiating  the  Outl  Output 
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D.3  Instantiate  Instances  of  the  REFINE-FUNCTION  Class 

Next  we  instantiate  the  two  REFINE-FUNCTION  instances  depicted  in  Figure  D.2. 
Select  the  REFINE-FUNCTION  class  as  illustrated  in  Figure  D.12.  As  before,  click  on 
“Object”  and  “New  Instance”  to  get  a  template  for  instantiating  the  REFINE-FUNCTION 
class.  Figure  D.13  amd  Figure  D.14  Me  the  two  instantiations  for  the  AND-GATE- 
UPDATEl  and  AND-GATE1-UPDATE2  functions  respectively. 


NAME 

DESCRIPTION 
CODE 
I  TYPE 


CLASS 


Abstract:  NIL 
Versumable;  NIL 
Documeot;  NIL 


OR-OATE 

PRESENTATION-DEVICE 

READ-DISR-STREAM 


REFINE-SOURCE-OBJ 

ROLE 

SCREEN-WINDOW 


Figure  D.12  Selecting  the  REFINE-FUNCTION  Class 
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D.5  Instantiate  Instances  of  the  CONCRETE  Class 


Now  instantiate  the  only  CONCRETE  class  for  this  example  depicted  in  Figure  D.2. 
Select  the  CONCRETE  class  as  illustrated  in  Figure  D.18.  Click  on  “Object”  and  “New 
Instance”  to  get  a  template  for  instantiating  the  CONCRETE  class.  Figure  D.19  is  the 
instantiation  for  the  And-Gate  CONCRETE  class. 


Figiure  D.18  Selecting  the  CONCRETE  Class 


Figure  D.19  Instantiating  the  CONCRETE  Class  for  And-Gate 


D-14 


D.  6  Instantiate  Instances  of  the  DOMAIN-DEF  Class 

Finally,  instantiate  the  DOMAIN-DEF  class  depicted  in  Figure  D.2.  Select  the 
DOMAIN-DEF  class  as  shown  in  Figure  D.20.  Click  on  “Object”  and  “New  Instance”  to 
get  a  template  for  instantiating  the  DOMAIN-DEF  class.  Figure  D.21  is  the  instantiation 
for  the  logic  circmts  DOMAIN-DEF  class. 

Notice  in  Figure  D.21  that  inside  the  window  labeled  ICO-OBJECT-CLASSES  there 
are  a  number  of  objects  with  labels  on  them.  These  objects  correspond  to  ABSTRACT 
and  CONCRETE  objects  we  instantiated  earlier  in  this  session.  They  are  put  in  the  ICO- 
OBJECT-CLASSES  attribute  by  clicking  on  am  objects  label  and  dragging  and  dropping 
it  into  this  window.  The  same  thing  is  done  for  the  ICO-DATA-OBJECTS  and  ICO- 
REFINE-FUNCTIONS  relationships  like  those  pictured  in  Figure  D.19. 

This  completes  the  process  of  loading  the  definition  of  a  domain  into  the  database. 
At  this  poinu  the  domain  knowledge  is  available  for  manipulation  and  transformation. 


Figure  D.20  Selecting  the  DOMAIN-DEF  Class 
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Appendix  E.  Sample  Session  :  OODBMS  Implementation  of  Technology  Base 

This  appendix  contains  a  sample  session  in  which  a  simple  application  for  a  light 
is  built  from  the  primitive  objects  defined  in  the  logic-circuits  domain,  wd  saved  to  the 
database.  The  circuit  diagram  for  the  Light  is  shown  in  Figure  E.l. 


THE-SWITCH  THE-LED 

Figmre  E.l  Light  Circuit 


E.l  Start  AVSI 

Refine  must  be  loaded  in  an  Emacs  window.  Once  this  is  accomplished  enter: 
(load  "dbl") 

When  the  prompt  returns,  enter: 

(dbl) 

It  will  take  several  minutes  for  this  file  to  nm  because  it  loads  the  DIALECT  and  iNTERVISTA 
systems  from  the  Unix  file  system,  and  loads  the  Architect  and  AVSI  files  from  the 
database.  When  the  loeid  is  complete,  the  following  prompt  appears: 

Load  Complete 

Type  "(AVSI)"  to  start  AVSI 
Now  enter  the  conunand: 

(avsl) 
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This  Eiction  loads  the  visual  specification  files  for  the  domains  currently  defined  for 
Architect.  After  the  visual  information  is  parsed  into  the  object  base,  the  control  panel 
appears  in  the  upper  left-hand  corner  of  the  screen.  Across  the  top  of  the  window  is  a 
row  of  icons  that  will  be  used  to  invoke  many  of  the  application  composition  functions  of 
AVSI.  The  lower  portion  of  the  window  is  a  message  area  used  by  AVSI  to  display  status 
and  error  messages. 

E.2  Create  a  New  Application 

1.  Chck  any  mouse  button  on  the  icon  labeled  CREATE  New  APPLICATION. 

2.  A  pop-up  window  appears  and  prompts,  Select  Domain.  Click  on  the  menu  item 
CIRCUITS.  At  this  time,  the  Circuits  domain  definition  is  loaded  from  the  database, 
as  are  the  bitmap  images  for  each  primitive. 

3.  A  pop-up  window  appears  with  the  prompt,  Enter  NAME  OF  APPLICATION.  Type 
light 

4.  The  name  can  be  entered  by  hitting  the  “return”  key  or  by  clicking  on  Do  IT  at  the 
bottom  of  the  pop-up  window. 

E.3  Edit  the  Application 

Now  that  the  application  hsis  been  created,  the  next  step  is  to  edit  the  application’s 
make-up.  Editing  2m  application  is  comprised  of  two  sepeirate  operations:  editing  an 
application’s  components,  and  editing  an  application’s  update  algorithm. 

E.3.1  Add  the  Controlling  Subsystem-obj  to  the  Application. 

1.  Click  a  mouse  button  on  the  Edit  Application  control  panel  icon. 

2.  A  pop-up  menu  appears  with  the  prompt  CHOOSE  Application.  Click  on  the  menu 
item  LIGHT. 
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3.  A  pop-up  menu  appears  with  the  prompt  CHOOSE.  Click  on  the  menu  item  Edit  Ap¬ 
plication  Components.  A  blue  window  appears  containing  a  single  icon  labeled, 

APPLICATION  -  OBJ 
LIGHT 

4.  Click  on  the  diagreun  surface  (anywhere  on  the  blue  surface  except  within  the  icon’s 
boimdzury)  of  the  window.  A  pop-up  menu  will  appear. 

5.  Select  CREATE  New  Subsystem. 

6.  A  pop-up  window  appears,  with  the  prompt  ENTER  A  NAME.  Enter  the-light 

7.  A  box  outline  of  an  icon  appears,  attached  to  the  mouse  cursor.  Place  the  icon  below 
the  application-obj  icon  by  moving  the  cursor  to  the  desired  location  and  clicking. 

8.  Click  any  mouse  button  on  the  newly  created  subsystem-obj  icon  and  select  the  menu 
option  Link  to  Source. 

9.  The  mouse  cursor  chzinges  from  an  arrow  to  an  oval  with  a  dot  in  it,  signifying  that 
an  object  needs  to  be  selected.  Place  the  mouse  cursor  on  the  application-obj ’s  icon 
and  click  any  mouse  button.  A  link  appears  between  the  application-obj ’s  icon  and 
the  subsystem-obj ’s  icon. 

10.  Close  the  edit-application- window  by  clicking  on  the  diagram  surface  and  selecting 
Deactivate. 

E.3.2  Create  the  Application-obj’s  Update  Algorithm. 

1.  Click  a  mouse  button  on  the  Edit  APPLICATION  control  panel  icon. 

2.  A  pop-up  menu  appears  with  the  prompt  CHOOSE  APPLICATION.  Click  on  the  menu 
item  LIGHT. 

3.  A  pop-up  menu  appears  with  the  prompt  CHOOSE.  Click  on  the  menu  item  EDIT 
Application  Update.  Three  windows  wiU  appear.  One  contains  a  graphical  view  of 
the  update  algorithm,  one  contains  a  textual  view  of  the  algorithm,  and  the  third  (the 
Controllee  Window)  shows  the  icons  that  represent  the  application-obj ’s  controUees 
(with  two  extra  icons  for  if-then  and  while-do  constructs).  The  graphical  update 


w 


window  contains  two  icons,  “Start”  and  “End”,  with  a  dotted  arrow  pointing  from 
the  start-icon  to  the  end-icon. 

4.  Click  a  mouse  button  on  the  icon  in  the  controUee  window  labeled  . 

THE  -  LIGHT 

The  cursor  chzuiges  to  an  oval  with  a  dot  in  it  indicating  that  an  object  needs  to  be 
selected. 

5.  Click  on  the  “nub”  on  the  dotted  line  midway  between  the  steurt  and  end  icons.  This 
will  cause  the  update  sequence  to  redraw  with  the  subsystem-obj  included.  Note  the 
textual  representation  is  automatically  updated  to  reflect  each  change  in  the  diagram 
window. 

6.  Close  the  edit-update-algorithm  windows  by  clicking  on  the  black  title  bar  at  the  top 
of  the  graphic2d  update  window  and  selecting  DEACTIVATE. 

E.4  Edit  the  Subsystems 

Building  a  subsystem  is  similar  to  building  the  application.  This  section  illustrates 
how  to  instantiate  primitive-objs  and  nested  subsystem-obj ’s  and  link  them  to  the  con¬ 
trolling  subsystem  created  in  the  previous  section. 

The  subsystem,  THE-LIGHT,  will  control  a  switch  and  an  LED.  To  add  these 
objects,  perform  the  following  steps: 

E.4-1  Add  the  Subsystem. 

1.  Click  on  the  Edit  Subsystem  icon  in  the  control  panel  window. 

2.  Click  on  the  menu  item  THE-LIGHT.  A  white  window  opens  (the  subsystem 
window)  wnich  contains  an  OCU  representation  of  a  subsystem. 

3.  Click  on  the  icon  in  the  subsystem  window.  The  blue  edit-subsystem- 

window  for  THE-LIGHT  appears,  containing  a  single  icon  labeled  . 

TRE  LIGHT 

A  green  window,  the  technology-base  window,  also  appears  and  contains  an  icon  for 
each  primitive-object  in  the  current  domain. 
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E.4-2  Add  the  Primitive  Objects. 


1.  Click  on  the  icon  in  the  green  technology-base-window  labeled  SWITCH-OBJ,  that 
looks  like  a  toggle  switch. 

2.  A  Switch-icon  is  created  and  attached  to  the  mouse  cursor.  Place  this  icon  on  the 
blue  edit-subsystem-window  near  THE-LIGHT. 

3.  Name  the  switch  by  typing  the-SWITCH  in  the  pop-up  window. 

4.  Similarily,  create  an  LED  object  named  the-led. 

5.  Link  the  primitive  objects  to  THE-LIGHT  by  clicking  a  mouse  button  on  THE- 
LIGHT,  and  selecting  LINK  MULTIPLE  Targets  from  the  pop-up  menu. 

6.  A  pop-up  window  will  appear  that  lists  all  the  imconnected  objects  in  the  edit- 
subsystem-window.  Select  All  OF  THE  ABOVE,  and  click  on  Do  It.  A  link  will 
appear  from  THE-LIGHT  to  each  of  the  other  icons. 

7.  Close  the  edit-subsystem-window  and  the  technology-base-window  by  clicking  on  the 
blue  surface  and  selecting  Deactivate.  The  windows  can  be  closed  separately  by 
selecting  DEACTIVATE  from  their  title  bu  menus. 

At  this  point,  the  subsystem  window  for  THE-LIGHT  will  again  be  visible. 

E.4.3  Connect  LIGHT’s  Imports  and  Exports.  To  connect  the  import  and  export 
objects  perform  the  following  steps: 

1.  Click  a  moxise  button  on  the  IMPORT  Area  or  EXPORT  Area  icon  in  LIGHT’s 
subsystem  window. 

2.  Select  Make  Connections  from  the  pop-up  window.  A  red  window  (the  import- 
export-window)  will  open  and  contain  the  switch  icon  and  the  led  icon.  The  black 
bars  (these  bars  are  actually  highlighted  subicons  attached  to  the  primitive’s  icon) 
on  the  sides  of  the  primitive  icons  indicate  connections  that  need  to  be  made. 

3.  Icons  ctm  be  moved  to  new  positions  on  the  screen  by  clicking  on  the  icon  sind 
selecting  Move  Icon  from  the  pop-up  menu.  A  square  grid,  attached  to  the  mouse. 
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appears.  Move  the  grid  to  the  new  icon  position  and  click  to  “drop”  the  icon.  Move 
the  LED  icon  to  the  right  of  the  SWITCH  icon  so  the  black  bars  are  facing  each 
other. 

4.  Connect  switch  THE-SWITCH  to  led  THE-LED  by  clicking  on  the  black  bar  of 
THE-SWITCH  and  then  clicking  on  the  black  bar  of  THE-LED. 

5.  Close  the  import-export- window  and  the  msp- windows  by  clicking  on  the  red  surface 
and  selecting  Deactivate,  or  by  selecting  Deactivate  from  each  window’s  title 
beur  menu. 

E.4.4  Build  THE-LIGHT’s  Update  Algorithm.  After  the  import-export  win¬ 
dows  have  been  closed,  the  white  subsystem  window  will  again  be  visible.  Building  the 
update  algorithm  for  THE-LIGHT  is  similar  to  building  the  update  algorithm  for  the 
application,  and  requires  the  following  steps: 

1.  Click  the  mouse  on  the  CONTROLLER  icon  in  the  subsystem  window.  The  three  win¬ 
dows  that  were  seen  before  are  exposed,  except  the  controUee  window  now  contains 
the  switch  and  led  controlled  by  THE-LIGHT. 

2.  Add  each  controUee  to  the  update  sequence  by  clicking  on  the  controUee  icon  and 
then  cUcking  on  the  “nub”  in  the  graphical  update  window  that  represents  the  proper 
sequence  position  for  the  controUee.  The  order  in  which  the  controUees  must  appear 
is: 

THE-SWITCH  THE-LED 

Note  that  the  textual  update  description  is  updated  as  the  graphical  update  is  built. 

3.  Close  the  windows  by  cUcking  on  the  graphical  update  window  title  bar  and  selecting 
Deactivate. 

E.5  Perform  Semantic  Checks 

Semantic  checks  are  performed  by  Architect  as  part  of  the  import-export  connection 
process.  However,  the  semantic  checks  may  be  nm  at  any  time  by  cUcking  on  the  control 
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panel  icon  labeled  Check  Semantics.  The  results  of  the  semantic  checks  may  be  viewed 
in  the  EMACS  window. 

E.6  Execute  the  Application 

Now  that  the  application  has  been  fully  defined,  it  can  be  executed.  The  default 
position  for  a  switch  is  "on”,  however  the  switch  attributes  can  be  changed  for  each 
execution.  To  set  the  switch  attributes,  do  the  following: 

1.  Click  on  the  control  panel’s  Edit  Subsystem  icon. 

2.  Choose  THE- LIGHT  from  the  pop-up  window. 

3.  Click  on  the  OBJECTS  icon  in  the  subsystem  window. 

4.  Click  on  the  switch  icon  labeled  THE-SWITCH. 

5.  Choose  View/Edit  attributes  from  the  pop-up  window.  A  window  appears, 
listing  the  switch  attributes  for  THE-SWITCH. 

6.  Click  on  the  attribute,  POSITION.  A  pop-up  window  appears,  listing  the  current 
value  of  the  switch. 

7.  Enter  a  new  value  for  the  switch  position  by  typing 
avsi: :off 

(The  “avsi::”  prefix  is  the  package  name  and  is  required  for  symbols.  It  is  not 
required  for  other  data  types  such  as  numbers  and  strings) 

Once  the  input  state  has  been  achieved,  click  on  the  control  panel  button  labeled 
Execute  Application.  The  resiUts  are  displayed  in  the  EMACS  window.  A  new  switch 
position  can  be  established,  and  the  application  can  be  re-executed. 

E.7  Save  the  Application  to  the  Database 

Now  that  the  application  has  been  successfully  composed,  it  can  be  saved  to  the 
database.  To  save  the  application,  do  the  following: 

1.  Click  on  the  control  panel’s  Edit  APPLICATION  icon. 
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2.  A  pop-up  menu  appears  with  the  prompt  CHOOSE  APPLICATION.  Click  on  the  menu 
item  LIGHT. 

3.  A  pop-up  menu  appeaurs  with  the  prompt  CHOOSE.  Click  on  the  menu  item  Save 
Application  to  Database.  The  application  will  now  be  copied  to  the  database. 
The  debug  information  for  the  database  tramsactions  should  appear  in  the  EMACS 
window. 

First,  an  OCU-APPLICATION  object  will  be  created,  and  its  Name,  Domain,  and 
Application- Mode  attributes  will  be  set  (refer  to  E.2). 


(apply  (Innctioii  MAKE)  (quota  (OCU-APPLICATIOI) ) ) 

(apply  (fnnction  SETF-SEID)  (quota  (lAME  t(851981  346  67)  IIL  LIGHT))) 

(apply  (function  SETF-SEID)  (quota  (DOHAII  *(851981  346  57)  IIL  CIRCUITS))) 

(apply  (function  SETF-SEID)  (quota  (APPLICATIOI-MODE  *(851981  346  57)  IIL 
HOI-EVEir-DRIVEI-SEQUEITlAL) )  ) _ 

Figure  E.2  OCU-APPLICATION  IVansaction 

Similarly,  the  OCU-SUBSYSTEM,  LED,  and  SWITCH  object  are  created.  An 
OCU-UPDATE-STATEMENT  is  created  with  the  OCU-SUBSYSTEM  as  its  Target  as¬ 
sociation  and  is  placed  in  the  OCU-APPLICATION  UPDATE-FUNCTION  2issociation. 
Two  more  OCU-UPDATE)-STATEMENT  objects  are  created  with  the  LED  and  SWITCH 
as  their  Targets  and  are  placed  in  the  OCU-SUBSYSTEM  UPDATE-FUNCTION 
association.  An  OCU-OUTPUT  is  created  for  the  SWITCH  and  its  attributes  are  updated, 
and  an  OCU-INPUT  is  created  and  updated  for  the  LED.  Once  all  of  the  objects  have 
been  created,  their  attributes  set,  and  their  associations  defined,  a  database  COMMIT  is 
sent.  This  signifies  the  end  of  the  database  transaction,  and  at  this  time  the  objects  2ure 
saved  in  the  database. 

E.8  Delete  the  Application  from  the  Database 

Since  this  was  merely  an  exercise  to  show  how  the  database  functionality  is  trans¬ 
parent  to  the  AVSI  user,  we  will  now  delete  the  application  from  the  database.  This  will 
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allow  other  users  to  perform  this  exercise  and  write  to  the  database.  In  order  to  delete  sm 
application  from  the  databsise,  do  the  following: 

1.  Click  any  mouse  button  on  the  icon  labeled  SAVED  APPLICATION  UTILITIES. 

2.  A  pop-up  window  appears  and  prompts,  ENTER  CHOICE.  Click  on  the  menu  item 
Remove  Application  from  Database. 

3.  A  pop-up  window  appears  and  prompts,  CHOOSE  Domain.  Click  on  the  menu  item 
CIRCUITS. 

4.  A  pop-up  window  appears  with  a  list  of  applications  ciurrently  stored  in  the  database 
for  the  Circuits  dommn.  Click  on  the  menu  item  LIGHT.  At  this  time,  the  applica¬ 
tion  will  be  removed  hrom  the  database.  Again,  the  database  transactions  will  scroll 
on  the  EMACS  window.  After  each  object  contained  within  the  application  has  been 
deleted,  a  COMMIT  is  sent  signalling  the  end  of  the  database  transaction.  At  this 
time,  the  objects  are  no  longer  accessible  in  the  database. 


E-9 


Bibliography 


1.  Anderson,  Cynthia.  Creating  and  Manipulating  Formalized  Software  Architectures 
in  Support  of  a  Domain- Oriented  Application  Composition  System.  MS  thesis, 
AFIT/GCS/ENG/92D-01,  Air  Force  Institute  of  Technology,  December  1992. 

2.  ASC/RWWW.  System  Concept  Document  for  the  Joint  Modeling  and  Simulation 
System  (J-MASS)  Program.  CROSSBOW-S  Architecture  Technical  Working  Group, 
November  1991. 

3.  Atkinson,  M^llcom,  et  al.  “The  Object-Oriented  Database  System  Manifesto.” 
Proceedings  of  the  First  International  Conference  on  Deductive  and  Object-Oriented 
Databases.  December  1989. 

4.  Bailor,  Major  Paul  D.,  “CSCE  793  -  Formal-Based  Methods  in  Software  Engineering.” 
Class  Notes,  1993. 

5.  Bailor,  Paul  D.  and  others.  “Formalization  ^lnd  Visualization  of  Domain-Specific 
Software  Architectures,”  AAAI-92  Workshop  on  Automated  Software  Design,  AAAI 
Conference,  6-11  (1992). 

6.  Cattell,  R.  G.  G.  Object  Data  Management.  Englewood  Cliffs,  New  Jersey:  Prentice 
Hall,  1991. 

7.  Colley,  Grzmt.  “Retain  the  Object  Model  and  Retain  the  Benefits,”  Object  Magazine 
(May  1992). 

8.  Cossentine,  Jay  A.  Developing  a  Sophisticated  User  Interface  to  Support  Domain- 
Oriented  Application  Composition  and  Generation  Systems.  MS  thesis.  Air  Force 
Institute  of  Technology,  December  1993. 

9.  D’Ippolito,  Rich2u:d  and  Keimeth  Lee.  “Modeling  Software  Systems  by  Domains.” 
Tenth  Automating  Software  Design  Workshop.  American  Association  for  Artificial 
Intelligence,  April  1992. 

10.  D’Ippolito,  Richard  S.  “Using  Models  in  Software  Engineering.”  Tri- Ada  Conference. 
256-265.  1989. 

11.  Gool,  Warren  E.  Alternative  Architectures  for  Domain-Oriented  Application 
Composition  and  Generation  Systems.  MS  thesis,  AFIT/GCS/ENG/93D-11,  Air 
Force  Institute  of  Technology,  December  1993. 

12.  Halloran,  Timothy  J.  Performance  Measurement  of  Three  Commercial  Object- 
Oriented  Database  Management  Systems.  MS  thesis,  AFIT/GCS/ENG/93D-12,  Air 
Force  Institute  of  Technology,  December  1993. 

13.  Harmon,  Paul.  “Object-Oriented  Database  Products,  Part  I,”  Object-Oriented 
Strategies,  ///(8)  (August  1993).  From  Cutter  Information  Corp. 

14.  Intellectic  International  SNC.  Matisse  2.1,0  Object  Editor  User’s  Guide  (First 
EJdition),  June  1992. 

15.  Intellectic  International  SNC.  Matisse  2.1.0  Server  Engine  Administrator’s  Guide 
(First  Edition),  Jime  1992. 


BIB-1 


16.  Kang,  Kyo  C.  and  others.  Feature- Oriented  Domain  Analysis  (FODA)  Feasibility 
Study.  Technical  Report  CMU/SEI-90-TR-21,  Software  Engineering  Institute, 
November  1990  (AD-A235  785). 

17.  Korth,  Henry  F.  and  Abraham  Silberschatz.  Database  System  Concepts.  New  York: 
McGraw-Hill,  Inc,  1991. 

18.  Lamb,  Charles,  et  al.  “The  ObjectStore  Database  System,”  Communications  of  the 
ACM,  5^(10)  (October  1991). 

19.  Lee,  Kenneth  J.  and  others.  Model-Based  Software  Development  (Draft).  Technical 
Report  CMU/SEI-92-SR-00,  Software  Engineering  Institute,  December  1991. 

20.  Lowry,  Michael  R.  “Software  Engineering  in  the  Twenty-first  Centiury.”  Automating 
Software  Design,  edited  by  Michael  R.  Lowry  and  Robert  D.  McCartney.  627-654. 
Menlo  Pzirk,  CA:  AAAI  Press,  1991. 

21.  Mallare,  Bradley  and  Mary  Boom.  Formalization  and  Transformation  of 
Informal  Analysis  Models  Into  Executable  Refine  Specifications.  MS  thesis, 
AFIT/GCS/ENG/92-04,  Air  Force  Institute  of  Technology,  December  1992. 

22.  Mano,  M.  Morris.  Computer  System  Architecture.  Englewood  Cliffs,  NJ:  Prentice- 
HaU,  Inc.,  1976. 

23.  Object  Management  Group.  The  Common  Object  Request  Broker:  Architecture 
and  Specification.  492  Old  Connecticut  Path,  Farmingham,  MA  01701:  Object 
Management  Group  and  X/Open,  1991. 

24.  Object  Management  Group.  Object  Management  Architecture  Guide.  492  Old 
Connecticut  Path,  Farmingham,  MA  01701:  Object  Msmagement  Group,  1992. 

25.  Ogush,  Mike.  “A  Software  Reuse  Lexicon,”  Cross  Talk,  41-45  (December  1992). 

26.  Randour,  Mary  Anne.  Creating  and  Manipulating  a  Domain-Specific  Formal  Object 
Base.  MS  thesis,  AFIT/GCS/ENG/92D-13,  Air  Force  Institute  of  Technology, 
December  1992. 

27.  Reasoning  Systems,  Inc.  Refine  User’s  Guide.  Reasoning  Systems,  Inc.,  Palo  Alto, 
California,  May  1990. 

28.  Roth,  Major  Mark  A.,  “CSCE  646  -  class  title??.”  Class  Notes,  1993. 

29.  Rumbaugh,  Jeimes,  et  al.  Object-Oriented  Modeling  and  Design.  Englewood  Cliffs, 
New  Jersey:  Prentice  Hedl,  1991. 

30.  Sandy,  Raleigh  A.  III.  A  Method  for  Populating  the  Knowledge  Base  of 
APTAS,  A  Domain-Oriented  Application  Composition  System.  MS  thesis, 
AFIT/GCE/ENG/93D-13,  Air  Force  Institute  of  Technology,  December  1993. 

31.  Stonebralcer,  Micheiel,  et  al.  “Third  Generation  Data  Base  System  Manifesto.” 
Proceedings  of  the  IFIP  DS-4  Workshop  on  Object-Oriented  Databases.  July  1990. 

32.  Sun  Microsystems,  Inc.,  “Introduction  to  the  ToolTalk  Service.”  A  White  Paper,  1992. 

33.  Waggoner,  Robert  W.  Domain  Modeling  of  Time-Dependent  Systems.  MS  thesis, 
AFIT/GCS/ENG/93D-23,  Air  Force  Institute  of  Technology,  December  1993. 


BIB-2 


34.  Warner,  Russell  M.  A  Method  for  Populating  the  Knowledge  Base  of  AFIT’s  Domain- 
Oriented  Application  Composition  System.  MS  thesis,  AFIT/GCS/ENG/93D-24,  Air 
Force  Institute  of  Technology,  December  1993. 

35.  Weide,  Timothy.  Development  of  a  Visual  System  for  a  Domain-Oriented  Application 
Composition  System.  MS  thesis,  AFIT/GCS/ENG/93M-05,  Air  Force  Institute  of 
Technology,  March  1993. 

36.  Welgan,  Robert  L.  Domain  Analysis  and  Modeling  of  a  Model-Based  Software 
Executive.  MS  thesis,  AFIT/GCS/ENG/93D-25,  Air  Force  Institute  of  Technology, 
December  1993. 


BIB-3 


Vita 


Captain  Danny  A.  Cecil  was  bom  on  May  8,  1958  in  Sidney,  Ohio  and  graduated 
from  Miami  East  High  School  in  Ceisstown,  Ohio  in  1976.  He  enlisted  in  the  Air  Force 
in  June  1976  emd  completed  technical  training  for  nuclear  weapons  maintenance  at  Lowry 
AFB,  Colorado  in  December  1976.  After  one  assignment  as  a  nuclear  weapons  technician  at 
Seymour  Johnson  AFB,  North  Carolina,  he  cross-trained  into  the  computer  programming 
career  field.  He  spent  four  years  as  a  programmer  at  Langley  AFB,  Virginia  before  being 
accepted  into  the  Airmen  Education  emd  Commissioning  Program.  He  attended  Wright 
State  University  in  Fairborn,  Ohio  fi-om  September  1984  to  July  1987.  Upon  graduating 
cum  laude  with  a  Bachelor  of  Science  in  Computer  Science  degree,  he  attended  Officer 
Trmning  School  and  received  his  commission  in  October  1987.  He  attended  the  Basic 
Commimications-Computer  Systems  course  at  Keesler  AFB,  Mississippi,  graduating  in 
February  1987.  He  was  rezissigned  to  Bergstrom  AFB,  Texas  where  he  provided  computer 
support  for  the  Twelfth  Air  Force  Air  Component  Commander’s  command  and  control 
commitments.  In  May  1992,  Captain  Cecil  entered  the  Air  Force  Institute  of  Technology 
at  Wright-Patterson  AFB,  Ohio  to  pursue  a  Master  of  Science  degree  with  a  concentration 
in  software  engineering. 


Permanent  address:  36  Regency  Sq 

Tipp  City,  Ohio  45371 


VITA-1 


Vita 


Captain  Joseph  A.  Fullenkamp  was  bom  on  February  22,  1959  in  Dayton,  Ohio  and 
greuluated  from  Mijunisburg  High  School  in  Miamisburg,  Ohio  in  1977.  He  enlisted  in 
the  Air  Force  in  March  1978  and  completed  technical  training  for  computer  operations 
at  Sheppard  AFB,  Texas  in  June  1978.  After  computer  operations  assignments  at  Dyess 
AFB,  Texas  8ind  Langley  AFB,  Virginia,  he  wsa  accepted  into  the  Airmen  Education  and 
Commissioning  Program  and  entered  Wright  State  University  at  Fairborn,  Ohio  in  June 
1986.  Upon  graduating  Summa  cum  laude  with  a  Bachelor  of  Science  in  Computer  Science 
degree  in  December  1987,  he  attended  Officer  Training  School  and  received  his  commission 
in  April  1988.  As  a  new  lieutenant,  he  attended  the  Basic  Communications-Computer  Sys¬ 
tems  course  at  Keesler  AFB,  Mississippi,  graduating  in  September  1987.  He  was  reassigned 
to  Scott  AFB,  niinois  where  he  maintained  the  system  software  supporting  Military  Airlift 
Command’s  world-wide  Consolidated  Aerial  Ports  Subsystems.  In  May  1992,  Captain 
Fullenkamp  entered  the  Air  Force  Institute  of  Technology  at  Wright-Patterson  AFB,  Ohio 
to  pursue  a  Master  of  Science  degree  in  Computer  Systems. 


Permanent  address:  2523  Sheridan  Road 

Omaha,  Nebraska  68123 


VITA-2 


REPORT  DOCUMENTATION  PAGE 


form  Appro^eo 
0MB  :'Jo  :}7C<i-Cia8 


'  ‘ 

.'  ■^•..31/c 3oroen 'or  •"IS  ■  ecT  ci^  s  *'  ■  : -*  *c  jOini;  tne  ti/ne ‘or  •cvnyw-r-  ^siruaions.  .eafTiin-;  •*»  s:  <“-3 sourres. 

^Atnerinq  ira  “*  untiining  tr'e  ■aaia  'leeoto.  rtmoie^inq  jno  r«-.  i».v  ^-3  •-#  -.ZHerr:  :“i  o?  inTor"“j*  '^-nq  ccmmen»i  .'•egarqmq  :r-s  surqen  ■•stifraie  cr  ,  trer  Thu 

rejection  OT  -• 'r-n^uen.  onuamg  sgggestic's 'rr  r*qucirq ‘h-s  c-'q®"  ::  -•®doa«jr*'»''<  iervicw.  directorate '0^  'iTcr-rat  on  Qaer^tiors  anq  -rs.  c'S  er*erson 

davis  riigrw4r  '....te ’204. -Xrnngtcn.  .  i  222 — 332.  iod  to  tne  J**  sno  ■soatie'  '30er<vorR  Pecuction  Pro.ect :  j?C4-0 ‘38),  Aavungtcft  T't  ::«w3 

j  1.  AGENCY  USE  ONLY  (Leave  olarxi 

2.  REPORT  DATE 

December  1993 

3.  REPORT  TYPE  AND  OATES  COVERED 

Master’s  Thesis 

,  4.  TITLE  AND  SUBTITLE 

Using  Database  Technology  to  Support  Domain-Oriented 
!  Application  Composition  Systems 

1 

1  5.  FUNDING  NUMBERS 

1 

1 

1 

1 

6.  AUTHOR(S)  i 

i 

Capt  Danny  A.  Cecil  j 

Capt  Joseph  A.  Fullenkamp  | 

7.  PERFORMING  ORGANIZATION  1AME(S)  AND  AODRESSiES) 

Air  Force  Institute  of  Technology,  WPAFB  OH  45433-6582 

1  3.  PE.RFORMING  CRGA.NiZATICN 
'  REPORT  NUMBER 

I  AFIT/GCS/ENG/93D-03 

i 

9.  SPONSORING/ MONITORING  AGENCY  NAME|S)  AND  AODRESSiES) 

Capt  Rick  Painter 

2241  Avionics  Circle,  Suite  16 

WL/AAWA-1  BLD  620 

Wright-Patterson  AFB,  OH  45433-7765 

.  10.  SPONSORING.  MONITORING 

I  AGENCY  REPORT  NUMBER 

I 

! 

i 

i 

1 

! 

1 

11.  SUPPLEMENTARY  NOTES 


;12a.  DISTRIBUTION /AVAILABILITY  STATEMENT 


Distribution  Unlimited 


12b.  DISTRIBUTION  CODE 


13.  ABSTRACT  (Maximum  200  words) 

This  research  designed  and  prototyped  an  OODBMS  technology  base  to  store  and  retrieve  various  types  of  domain 
artifacts  for  domain-oriented  application  composition  systems  (DOACS).  We  developed  object-oriented  database 
schemas  for  a  validating  domain  and  the  Object-Connection-Update  software  architecture.  We  implemented  an 
inheritance  relationship  between  the  schemas  so  a  domain  model  can  inherit  an  architectural  structure  from  an 
architecture  model  aUowing  us  to  isolate  domain-specific  knowledge  &om  architecture-specific  knowledge.  We 
also  developed  a  meta-model  to  formally  define  domain  models  in  the  database.  We  then  developed  a  set  of 
database  methods  to  transform  a  domain  model  into  a  database  schema  for  storing  artifacts  from  the  domain  and 
to  automatically  populate  the  DOACS  object  base  with  the  domain  definition.  Using  an  OODBMS,  the  structure 
and  relationships  that  provide  much  of  the  power  in  object  models  are  retained  because  the  artificial  flattening 
required  for  storage  in  traditional  databases  and  file  systems  is  prevented.  Isolating  domain  and  architecture 
models  from  each  other  has  greatly  increased  the  reusability  of  the  domain  artifacts,  the  domain  model,  and  the 
architecture  model.  The  Inheritance  relationship  between  domain  and  architecture  models  allows  a  domsdn  to 
be  defined  once,  but  used  in  many  different  architectural  environments  and  vice  versa. 


14.  SUBJECT  TERMS 

computers,  computer  programs,  software  engineering,  specifications, 
software  architecture  models,  application  composition  systems, 
domain  modeling,  database,  object-oriented  database 


17.  SECURITY  CLASSIFICATION 
OF  REPORT 

UNCLASSIFIED 


18.  SECURITY  CLASSIFICATION 
OF  THIS  PAGE 

UNCLASSIFIED 


19.  SECURITY  CLASSIFICATION 
OF  ABSTRACT 

UNCLASSIFIED 


IS.  NUMBER  OF  PAGES 
223 


16.  PRICE  COOE 


20.  LIMITATION  OF  ABSTRACT 

UL 


NSN  7540-01-280-5500 


Standard  Form  298  (Rev  2-89) 

Prescribed  by  ANSI  Std  Z39«'8 
298-102 


